nvfx

nvfx

[Xavier Chantry]

Hi Marek

Thanks a lot for your rebasing work.
Here is my report :

- all my games that broke with temporaries patch (they were either
completely black or lot of black screen flash every frame) behave
badly, but in different ways :
* etracer is very slow and often crash in ttm code [1] (I think this
is an old bug that just resurrected, no idea why)
* foobillard is very slow and still flash a bit
* strangely, neverball seems to work, I get similar results than with
old nvfx-next-6b branch with temporaries reverted. no black flash
while playing.
* glest segfault [2]

I also compared with piglit the old nvfx branch with the new merged one :
114/174 vs 113/174
That looks quite good with 3 new pass, but 4 new fail :
* fbo-copypix
Returncode was -6
* glean pbo
     ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference:
Assertion `pipe_is_referenced(reference)\\\' failed.
* texCombine4:  FAIL rgba8, db, z24, s8, win+pmap, id 33
* fp-long-alu

There is just fp-long-alu that is for sure a regression caused by new
master code (some gallium changes). I don't know about the 3 others.

It might be worth to re-test everything on your new branch with this
patch reverted :
nvfx: rewrite render temporaries code, also affecting 2D and resource code



[1]
Jun 11 15:08:00 myhost kernel: [ 8670.323229] BUG: unable to handle
kernel paging request at 0007000d
Jun 11 15:08:00 myhost kernel: [ 8670.323242] IP: [<f840adcb>]
ttm_bo_wait+0x1b/0x170 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323260] *pde = 00000000
Jun 11 15:08:00 myhost kernel: [ 8670.323265] Oops: 0000 [#1] PREEMPT SMP
Jun 11 15:08:00 myhost kernel: [ 8670.323271] last sysfs file:
/sys/devices/platform/w83627hf.656/temp2_input
Jun 11 15:08:00 myhost kernel: [ 8670.323278] Modules linked in:
w83627hf hwmon_vid nfs lockd nfs_acl auth_rpcgss sunrpc fuse
hid_logitech ff_memless usbhid
 hid snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1
snd_rawmidi snd_pcm_oss snd_seq_device nouveau ttm drm_kms_helper
snd_mixer_oss snd_ut
il_mem snd_hwdep drm i2c_algo_bit snd_intel8x0 snd_ac97_codec ac97_bus
firewire_ohci firewire_core emu10k1_gp crc_itu_t i82875p_edac evdev
ppdev snd_pcm snd
_timer gameport e1000 edac_core parport_pc snd soundcore
snd_page_alloc psmouse uhci_hcd i2c_i801 intel_agp button thermal
processor iTCO_wdt iTCO_vendor_support serio_raw i2c_core ehci_hcd
agpgart shpchp pci_hotplug usbcore lp parport rtc_cmos rtc_core
rtc_lib dm_mirror dm_region_hash dm_log dm_mod
Jun 11 15:08:00 myhost kernel: [ 8670.323367]
Jun 11 15:08:00 myhost kernel: [ 8670.323373] Pid: 5723, comm: etracer
Not tainted 2.6.34-rc5 #21 P4C800-E/To Be Filled By O.E.M.
Jun 11 15:08:00 myhost kernel: [ 8670.323378] EIP: 0060:[<f840adcb>]
EFLAGS: 00210282 CPU: 0
Jun 11 15:08:00 myhost kernel: [ 8670.323386] EIP is at
ttm_bo_wait+0x1b/0x170 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323390] EAX: 00070001 EBX:
f4700900 ECX: 00000000 EDX: 00000000
Jun 11 15:08:00 myhost kernel: [ 8670.323394] ESI: 00000000 EDI:
00000000 EBP: f100bb50 ESP: f100bb20
Jun 11 15:08:00 myhost kernel: [ 8670.323398]  DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Jun 11 15:08:00 myhost kernel: [ 8670.323402] Process etracer (pid:
5723, ti=f100a000 task=f387c840 task.ti=f100a000)
Jun 11 15:08:00 myhost kernel: [ 8670.323406] Stack:
Jun 11 15:08:00 myhost kernel: [ 8670.323408]  00000000 00000000
00200002 00000000 0100bb3c f470095c 00000000 00000000
Jun 11 15:08:00 myhost kernel: [ 8670.323418] <0> 00000000 f4700900
00000000 f4700928 f100bbcc f840c35f 00000000 00000000
Jun 11 15:08:00 myhost kernel: [ 8670.323429] <0> f100bc98 f100bc98
0000eeee f100bc38 00004000 00000000 f4700910 00070001
Jun 11 15:08:00 myhost kernel: [ 8670.323441] Call Trace:
Jun 11 15:08:00 myhost kernel: [ 8670.323451]  [<f840c35f>] ?
ttm_mem_evict_first+0x12f/0x4a0 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323460]  [<f840ba19>] ?
ttm_bo_man_get_node+0xb9/0xc0 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323468]  [<f840ce5d>] ?
ttm_bo_mem_space+0x36d/0x430 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323486]  [<f84bd183>] ?
nouveau_bo_move+0x193/0x410 [nouveau]
Jun 11 15:08:00 myhost kernel: [ 8670.323498]  [<c106c805>] ?
generic_smp_call_function_single_interrupt+0x95/0xd0
Jun 11 15:08:00 myhost kernel: [ 8670.323511]  [<f84bcff0>] ?
nouveau_bo_move+0x0/0x410 [nouveau]
Jun 11 15:08:00 myhost kernel: [ 8670.323519]  [<f840b3d7>] ?
ttm_bo_handle_move_mem+0xf7/0x330 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323527]  [<f840d01d>] ?
ttm_bo_move_buffer+0xfd/0x120 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323535]  [<f840d0ce>] ?
ttm_bo_validate+0x8e/0x120 [ttm]
Jun 11 15:08:00 myhost kernel: [ 8670.323547]  [<f84bd9a5>] ?
validate_list+0xa5/0x280 [nouveau]
Jun 11 15:08:00 myhost kernel: [ 8670.323561]  [<f84be6a0>] ?
nouveau_gem_ioctl_pushbuf+0x5f0/0xea0 [nouveau]
Jun 11 15:08:00 myhost kernel: [ 8670.323576]  [<f83ce3ac>] ?
drm_ioctl+0x28c/0x410 [drm]
Jun 11 15:08:00 myhost kernel: [ 8670.323589]  [<f84be0b0>] ?
nouveau_gem_ioctl_pushbuf+0x0/0xea0 [nouveau]
Jun 11 15:08:00 myhost kernel: [ 8670.323601]  [<c1035e86>] ?
task_tick_fair+0x36/0xf0
Jun 11 15:08:00 myhost kernel: [ 8670.323609]  [<c10e8554>] ?
vfs_ioctl+0x34/0xa0
Jun 11 15:08:00 myhost kernel: [ 8670.323616]  [<c1088d4a>] ?
rcu_report_qs_rnp+0x6a/0x100
Jun 11 15:08:00 myhost kernel: [ 8670.323626]  [<f83ce120>] ?
drm_ioctl+0x0/0x410 [drm]
Jun 11 15:08:00 myhost kernel: [ 8670.323631]  [<c10e8d06>] ?
do_vfs_ioctl+0x66/0x580
Jun 11 15:08:00 myhost kernel: [ 8670.323638]  [<c10431c0>] ?
__do_softirq+0xe0/0x1d0
Jun 11 15:08:00 myhost kernel: [ 8670.323644]  [<c10e927f>] ?
sys_ioctl+0x5f/0x80
Jun 11 15:08:00 myhost kernel: [ 8670.323652]  [<c101c436>] ?
smp_apic_timer_interrupt+0x56/0x90
Jun 11 15:08:00 myhost kernel: [ 8670.323660]  [<c100381f>] ?
sysenter_do_call+0x12/0x28
Jun 11 15:08:00 myhost kernel: [ 8670.323663] Code: 0f 0b 0f 0b 8d b6
00 00 00 00 8d bf 00 00 00 00 55 89 e5 83 ec 30 89 5d f4 89 c3 89 7d
fc 0f b6 7d 08 89 75 f8 88 4d e8 8b 40 04 <8b> 70 0c 8b 83 8c 00 00 00
85 c0 75 11 31 d2 8b 5d f4 89 d0 8b
Jun 11 15:08:00 myhost kernel: [ 8670.323727] EIP: [<f840adcb>]
ttm_bo_wait+0x1b/0x170 [ttm] SS:ESP 0068:f100bb20
Jun 11 15:08:00 myhost kernel: [ 8670.323737] CR2: 000000000007000d
Jun 11 15:08:00 myhost kernel: [ 8670.323744] ---[ end trace
6da3a079cf5aebe6 ]---

[2]
*** glibc detected *** ./glest: invalid fastbin entry (free): 0x09bc2938 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6c7b1)[0xb6fa67b1]
/lib/libc.so.6(+0x6d52b)[0xb6fa752b]
/lib/libc.so.6(cfree+0x6d)[0xb6fab1cd]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x1f837d)[0xb614837d]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x1f845b)[0xb614845b]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x1f829c)[0xb614829c]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x1f8513)[0xb6148513]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x1cdb72)[0xb611db72]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x1cf947)[0xb611f947]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x1154e)[0xb5f6154e]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x18cf4)[0xb5f68cf4]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x17e42a)[0xb60ce42a]
/home/xavier/app/mesa/lib/gallium/nouveau_dri.so(+0x67d2c)[0xb5fb7d2c]
./glest[0x80898f7]
./glest[0x808bf48]
./glest[0x808b310]
./glest[0x808b6f8]
/lib/libc.so.6(__libc_start_main+0xe6)[0xb6f50c76]
./glest[0x804e0f1]
======= Memory map: ========

Re: nvfx

[Xavier Chantry]

On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry
<chantry.xavier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Marek
>
> Thanks a lot for your rebasing work.

Sorry, I forgot to include the repo link, which was given in #dri-devel :
git://anongit.freedesktop.org/~mareko/mesa nvfx-next-6b
pmdata just asked it in #nouveau

Re: nvfx

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 2012 bytes --]

On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry <chantry.xavier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:

> Hi Marek
>
> Thanks a lot for your rebasing work.
> Here is my report :
>
> - all my games that broke with temporaries patch (they were either
> completely black or lot of black screen flash every frame) behave
> badly, but in different ways :
> * etracer is very slow and often crash in ttm code [1] (I think this
> is an old bug that just resurrected, no idea why)
> * foobillard is very slow and still flash a bit
> * strangely, neverball seems to work, I get similar results than with
> old nvfx-next-6b branch with temporaries reverted. no black flash
> while playing.
> * glest segfault [2]
>
> I also compared with piglit the old nvfx branch with the new merged one :
> 114/174 vs 113/174
> That looks quite good with 3 new pass, but 4 new fail :
> * fbo-copypix
> Returncode was -6
> * glean pbo
>     ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference:
> Assertion `pipe_is_referenced(reference)\\\' failed.
> * texCombine4:  FAIL rgba8, db, z24, s8, win+pmap, id 33
> * fp-long-alu
>

Hi Xavier,

Sorry for the late reply.

The assertion in pipe_reference can be fixed quite easily I think. There is
pipe_*_reference missing somewhere.

Concerning fp-long-alu, there are new CAPs for shader limits which should be
filled out but I don't know what values to put there. If the two get fixed,
it will hopefully be just 2 new failures along with 3 that pass.


> There is just fp-long-alu that is for sure a regression caused by new
> master code (some gallium changes). I don't know about the 3 others.
>
> It might be worth to re-test everything on your new branch with this
> patch reverted :
> nvfx: rewrite render temporaries code, also affecting 2D and resource code
>

Here is the tree with the commit reverted:

git://anongit.freedesktop.org/~mareko/mesa nvfx-next-6b-notemps

It is compile-tested so if it does not work, there is nothing I can do about
it.

-Marek

[-- Attachment #1.2: Type: text/html, Size: 2718 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Patrice Mandin]

Le Thu, 17 Jun 2010 03:35:19 +0200
Marek Olšák <maraeo@gmail.com> a écrit:

> On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry <chantry.xavier@gmail.com>wrote:
> 
> > Hi Marek
> >
> > Thanks a lot for your rebasing work.
> > Here is my report :
> >
> > - all my games that broke with temporaries patch (they were either
> > completely black or lot of black screen flash every frame) behave
> > badly, but in different ways :
> > * etracer is very slow and often crash in ttm code [1] (I think this
> > is an old bug that just resurrected, no idea why)
> > * foobillard is very slow and still flash a bit
> > * strangely, neverball seems to work, I get similar results than with
> > old nvfx-next-6b branch with temporaries reverted. no black flash
> > while playing.
> > * glest segfault [2]
> >
> > I also compared with piglit the old nvfx branch with the new merged one :
> > 114/174 vs 113/174
> > That looks quite good with 3 new pass, but 4 new fail :
> > * fbo-copypix
> > Returncode was -6
> > * glean pbo
> >     ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference:
> > Assertion `pipe_is_referenced(reference)\\\' failed.
> > * texCombine4:  FAIL rgba8, db, z24, s8, win+pmap, id 33
> > * fp-long-alu
> >
> 
> Hi Xavier,
> 
> Sorry for the late reply.
> 
> The assertion in pipe_reference can be fixed quite easily I think. There is
> pipe_*_reference missing somewhere.
> 
> Concerning fp-long-alu, there are new CAPs for shader limits which should be
> filled out but I don't know what values to put there. If the two get fixed,
> it will hopefully be just 2 new failures along with 3 that pass.
> 
> 
> > There is just fp-long-alu that is for sure a regression caused by new
> > master code (some gallium changes). I don't know about the 3 others.
> >
> > It might be worth to re-test everything on your new branch with this
> > patch reverted :
> > nvfx: rewrite render temporaries code, also affecting 2D and resource code
> >
> 
> Here is the tree with the commit reverted:
> 
> git://anongit.freedesktop.org/~mareko/mesa nvfx-next-6b-notemps
> 
> It is compile-tested so if it does not work, there is nothing I can do about
> it.
> 
> -Marek

I just tested the new tree nvfx-next-6b-notemps, I think we should go
some commits before, because Luca removed the check in fbo setting
between difference in bits between colour and depth/stencil buffer, and
nv30 hw does not support that (they must be equal) and doing that
simply hang the gpu.

Commit 4787059263755fb92b2bb09ac71658d9b4cc9368 'nvfx: new 2D: add
support for render temporaries' removed this check and fbo tests
trigger the bug. Maybe Luca was planning to use temporaries to avoid
this check, but unfortunately we do not know if he finished it or not.

-- 
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

"who writes the code, decides"


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 3493 bytes --]

On Fri, Jun 18, 2010 at 6:05 PM, Patrice Mandin <mandin.patrice-1tsiiZ//OF9QFI55V6+gNQ@public.gmane.org>wrote:

> Le Thu, 17 Jun 2010 03:35:19 +0200
> Marek Olšák <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> a écrit:
>
> > On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry <
> chantry.xavier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
> >
> > > Hi Marek
> > >
> > > Thanks a lot for your rebasing work.
> > > Here is my report :
> > >
> > > - all my games that broke with temporaries patch (they were either
> > > completely black or lot of black screen flash every frame) behave
> > > badly, but in different ways :
> > > * etracer is very slow and often crash in ttm code [1] (I think this
> > > is an old bug that just resurrected, no idea why)
> > > * foobillard is very slow and still flash a bit
> > > * strangely, neverball seems to work, I get similar results than with
> > > old nvfx-next-6b branch with temporaries reverted. no black flash
> > > while playing.
> > > * glest segfault [2]
> > >
> > > I also compared with piglit the old nvfx branch with the new merged one
> :
> > > 114/174 vs 113/174
> > > That looks quite good with 3 new pass, but 4 new fail :
> > > * fbo-copypix
> > > Returncode was -6
> > > * glean pbo
> > >
> ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference:
> > > Assertion `pipe_is_referenced(reference)\\\' failed.
> > > * texCombine4:  FAIL rgba8, db, z24, s8, win+pmap, id 33
> > > * fp-long-alu
> > >
> >
> > Hi Xavier,
> >
> > Sorry for the late reply.
> >
> > The assertion in pipe_reference can be fixed quite easily I think. There
> is
> > pipe_*_reference missing somewhere.
> >
> > Concerning fp-long-alu, there are new CAPs for shader limits which should
> be
> > filled out but I don't know what values to put there. If the two get
> fixed,
> > it will hopefully be just 2 new failures along with 3 that pass.
> >
> >
> > > There is just fp-long-alu that is for sure a regression caused by new
> > > master code (some gallium changes). I don't know about the 3 others.
> > >
> > > It might be worth to re-test everything on your new branch with this
> > > patch reverted :
> > > nvfx: rewrite render temporaries code, also affecting 2D and resource
> code
> > >
> >
> > Here is the tree with the commit reverted:
> >
> > git://anongit.freedesktop.org/~mareko/mesa<http://anongit.freedesktop.org/%7Emareko/mesa>nvfx-next-6b-notemps
> >
> > It is compile-tested so if it does not work, there is nothing I can do
> about
> > it.
> >
> > -Marek
>
> I just tested the new tree nvfx-next-6b-notemps, I think we should go
> some commits before, because Luca removed the check in fbo setting
> between difference in bits between colour and depth/stencil buffer, and
> nv30 hw does not support that (they must be equal) and doing that
> simply hang the gpu.
>
> Commit 4787059263755fb92b2bb09ac71658d9b4cc9368 'nvfx: new 2D: add
> support for render temporaries' removed this check and fbo tests
> trigger the bug. Maybe Luca was planning to use temporaries to avoid
> this check, but unfortunately we do not know if he finished it or not.
>

I do not want to guess here. I would like to hear something from Luca before
doing anything else with his code.

-Marek


> --
> Patrice Mandin
> WWW: http://pmandin.atari.org/
> Programmeur Linux, Atari
> Spécialité: Développement, jeux
>
> "who writes the code, decides"
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 4683 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Patrice Mandin]

Le Fri, 18 Jun 2010 18:43:27 +0200
Marek Olšák <maraeo@gmail.com> a écrit:

> I do not want to guess here. I would like to hear something from Luca before
> doing anything else with his code.

OK, so if Luca does not show up soon to tell us more about it, someone
(me?) will have to fix/finish his work. I just wanted to point about
the issues I know. If you want to merge, I'm OK with it.

-- 
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

"who writes the code, decides"


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Patrice Mandin]

Le Fri, 18 Jun 2010 18:43:27 +0200
Marek Olšák <maraeo@gmail.com> a écrit:

> On Fri, Jun 18, 2010 at 6:05 PM, Patrice Mandin <mandin.patrice@orange.fr>wrote:
> 
> > Le Thu, 17 Jun 2010 03:35:19 +0200
> > Marek Olšák <maraeo@gmail.com> a écrit:
> >
> > > On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry <
> > chantry.xavier@gmail.com>wrote:
> > >
> > > > Hi Marek
> > > >
> > > > Thanks a lot for your rebasing work.
> > > > Here is my report :
> > > >
> > > > - all my games that broke with temporaries patch (they were either
> > > > completely black or lot of black screen flash every frame) behave
> > > > badly, but in different ways :
> > > > * etracer is very slow and often crash in ttm code [1] (I think this
> > > > is an old bug that just resurrected, no idea why)
> > > > * foobillard is very slow and still flash a bit
> > > > * strangely, neverball seems to work, I get similar results than with
> > > > old nvfx-next-6b branch with temporaries reverted. no black flash
> > > > while playing.
> > > > * glest segfault [2]
> > > >
> > > > I also compared with piglit the old nvfx branch with the new merged one
> > :
> > > > 114/174 vs 113/174
> > > > That looks quite good with 3 new pass, but 4 new fail :
> > > > * fbo-copypix
> > > > Returncode was -6
> > > > * glean pbo
> > > >
> > ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference:
> > > > Assertion `pipe_is_referenced(reference)\\\' failed.
> > > > * texCombine4:  FAIL rgba8, db, z24, s8, win+pmap, id 33
> > > > * fp-long-alu
> > > >
> > >
> > > Hi Xavier,
> > >
> > > Sorry for the late reply.
> > >
> > > The assertion in pipe_reference can be fixed quite easily I think. There
> > is
> > > pipe_*_reference missing somewhere.
> > >
> > > Concerning fp-long-alu, there are new CAPs for shader limits which should
> > be
> > > filled out but I don't know what values to put there. If the two get
> > fixed,
> > > it will hopefully be just 2 new failures along with 3 that pass.
> > >
> > >
> > > > There is just fp-long-alu that is for sure a regression caused by new
> > > > master code (some gallium changes). I don't know about the 3 others.
> > > >
> > > > It might be worth to re-test everything on your new branch with this
> > > > patch reverted :
> > > > nvfx: rewrite render temporaries code, also affecting 2D and resource
> > code
> > > >
> > >
> > > Here is the tree with the commit reverted:
> > >
> > > git://anongit.freedesktop.org/~mareko/mesa<http://anongit.freedesktop.org/%7Emareko/mesa>nvfx-next-6b-notemps
> > >
> > > It is compile-tested so if it does not work, there is nothing I can do
> > about
> > > it.
> > >
> > > -Marek
> >
> > I just tested the new tree nvfx-next-6b-notemps, I think we should go
> > some commits before, because Luca removed the check in fbo setting
> > between difference in bits between colour and depth/stencil buffer, and
> > nv30 hw does not support that (they must be equal) and doing that
> > simply hang the gpu.
> >
> > Commit 4787059263755fb92b2bb09ac71658d9b4cc9368 'nvfx: new 2D: add
> > support for render temporaries' removed this check and fbo tests
> > trigger the bug. Maybe Luca was planning to use temporaries to avoid
> > this check, but unfortunately we do not know if he finished it or not.
> 
> I do not want to guess here. I would like to hear something from Luca before
> doing anything else with his code.

It has been 3 months since latest Luca's sign, and I'm afraid it will
be a while before it changes :-(.

Marek, if you are still interested in merging stuff from nvfx-next-6b,
I would like to propose up to commit
9a4c66b0d1963c4d90fccac41e7aa48105835857 included (as I said before,
the following ones bring back nasty regression regarding fbo stuff,
hanging the gpu hard).

Luca did many fixes in his branch so it's really bad these ones are not
merged back to master. Also, I don't feel like touching the nvfx
backend in master till these fixes are merged.

-- 
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

"who writes the code, decides"


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Marek Olšák]

[-- Attachment #1.1: Type: text/plain, Size: 4578 bytes --]

On Fri, Jul 23, 2010 at 7:01 PM, Patrice Mandin <mandin.patrice-1tsiiZ//OF9QFI55V6+gNQ@public.gmane.org>wrote:

> Le Fri, 18 Jun 2010 18:43:27 +0200
> Marek Olšák <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> a écrit:
>
> > On Fri, Jun 18, 2010 at 6:05 PM, Patrice Mandin <
> mandin.patrice-1tsiiZ//OF9QFI55V6+gNQ@public.gmane.org>wrote:
> >
> > > Le Thu, 17 Jun 2010 03:35:19 +0200
> > > Marek Olšák <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> a écrit:
> > >
> > > > On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry <
> > > chantry.xavier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
> > > >
> > > > > Hi Marek
> > > > >
> > > > > Thanks a lot for your rebasing work.
> > > > > Here is my report :
> > > > >
> > > > > - all my games that broke with temporaries patch (they were either
> > > > > completely black or lot of black screen flash every frame) behave
> > > > > badly, but in different ways :
> > > > > * etracer is very slow and often crash in ttm code [1] (I think
> this
> > > > > is an old bug that just resurrected, no idea why)
> > > > > * foobillard is very slow and still flash a bit
> > > > > * strangely, neverball seems to work, I get similar results than
> with
> > > > > old nvfx-next-6b branch with temporaries reverted. no black flash
> > > > > while playing.
> > > > > * glest segfault [2]
> > > > >
> > > > > I also compared with piglit the old nvfx branch with the new merged
> one
> > > :
> > > > > 114/174 vs 113/174
> > > > > That looks quite good with 3 new pass, but 4 new fail :
> > > > > * fbo-copypix
> > > > > Returncode was -6
> > > > > * glean pbo
> > > > >
> > > ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference:
> > > > > Assertion `pipe_is_referenced(reference)\\\' failed.
> > > > > * texCombine4:  FAIL rgba8, db, z24, s8, win+pmap, id 33
> > > > > * fp-long-alu
> > > > >
> > > >
> > > > Hi Xavier,
> > > >
> > > > Sorry for the late reply.
> > > >
> > > > The assertion in pipe_reference can be fixed quite easily I think.
> There
> > > is
> > > > pipe_*_reference missing somewhere.
> > > >
> > > > Concerning fp-long-alu, there are new CAPs for shader limits which
> should
> > > be
> > > > filled out but I don't know what values to put there. If the two get
> > > fixed,
> > > > it will hopefully be just 2 new failures along with 3 that pass.
> > > >
> > > >
> > > > > There is just fp-long-alu that is for sure a regression caused by
> new
> > > > > master code (some gallium changes). I don't know about the 3
> others.
> > > > >
> > > > > It might be worth to re-test everything on your new branch with
> this
> > > > > patch reverted :
> > > > > nvfx: rewrite render temporaries code, also affecting 2D and
> resource
> > > code
> > > > >
> > > >
> > > > Here is the tree with the commit reverted:
> > > >
> > > > git://anongit.freedesktop.org/~mareko/mesa<http://anongit.freedesktop.org/%7Emareko/mesa>
> <http://anongit.freedesktop.org/%7Emareko/mesa>nvfx-next-6b-notemps
> > > >
> > > > It is compile-tested so if it does not work, there is nothing I can
> do
> > > about
> > > > it.
> > > >
> > > > -Marek
> > >
> > > I just tested the new tree nvfx-next-6b-notemps, I think we should go
> > > some commits before, because Luca removed the check in fbo setting
> > > between difference in bits between colour and depth/stencil buffer, and
> > > nv30 hw does not support that (they must be equal) and doing that
> > > simply hang the gpu.
> > >
> > > Commit 4787059263755fb92b2bb09ac71658d9b4cc9368 'nvfx: new 2D: add
> > > support for render temporaries' removed this check and fbo tests
> > > trigger the bug. Maybe Luca was planning to use temporaries to avoid
> > > this check, but unfortunately we do not know if he finished it or not.
> >
> > I do not want to guess here. I would like to hear something from Luca
> before
> > doing anything else with his code.
>
> It has been 3 months since latest Luca's sign, and I'm afraid it will
> be a while before it changes :-(.
>
> Marek, if you are still interested in merging stuff from nvfx-next-6b,
> I would like to propose up to commit
> 9a4c66b0d1963c4d90fccac41e7aa48105835857 included (as I said before,
> the following ones bring back nasty regression regarding fbo stuff,
> hanging the gpu hard).
>

9a4c66b0d1963c4d90fccac41e7aa48105835857 doesn't compile, so I went one
commit back.

It's here for testing:
git://anongit.freedesktop.org/~mareko/mesa nvfx-new

Please let me know if it works.

-Marek

[-- Attachment #1.2: Type: text/html, Size: 6439 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Luca Barbieri]

On Fri, Jul 23, 2010 at 7:01 PM, Patrice Mandin
<mandin.patrice@orange.fr> wrote:
> Le Fri, 18 Jun 2010 18:43:27 +0200
> Marek Olšák <maraeo@gmail.com> a écrit:
>
>> On Fri, Jun 18, 2010 at 6:05 PM, Patrice Mandin <mandin.patrice@orange.fr>wrote:
>>
>> > Le Thu, 17 Jun 2010 03:35:19 +0200
>> > Marek Olšák <maraeo@gmail.com> a écrit:
>> >
>> > > On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry <
>> > chantry.xavier@gmail.com>wrote:
>> > >
>> > > > Hi Marek
>> > > >
>> > > > Thanks a lot for your rebasing work.
>> > > > Here is my report :
>> > > >
>> > > > - all my games that broke with temporaries patch (they were either
>> > > > completely black or lot of black screen flash every frame) behave
>> > > > badly, but in different ways :
>> > > > * etracer is very slow and often crash in ttm code [1] (I think this
>> > > > is an old bug that just resurrected, no idea why)
>> > > > * foobillard is very slow and still flash a bit
>> > > > * strangely, neverball seems to work, I get similar results than with
>> > > > old nvfx-next-6b branch with temporaries reverted. no black flash
>> > > > while playing.
>> > > > * glest segfault [2]
>> > > >
>> > > > I also compared with piglit the old nvfx branch with the new merged one
>> > :
>> > > > 114/174 vs 113/174
>> > > > That looks quite good with 3 new pass, but 4 new fail :
>> > > > * fbo-copypix
>> > > > Returncode was -6
>> > > > * glean pbo
>> > > >
>> > ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference:
>> > > > Assertion `pipe_is_referenced(reference)\\\' failed.
>> > > > * texCombine4:  FAIL rgba8, db, z24, s8, win+pmap, id 33
>> > > > * fp-long-alu
>> > > >
>> > >
>> > > Hi Xavier,
>> > >
>> > > Sorry for the late reply.
>> > >
>> > > The assertion in pipe_reference can be fixed quite easily I think. There
>> > is
>> > > pipe_*_reference missing somewhere.
>> > >
>> > > Concerning fp-long-alu, there are new CAPs for shader limits which should
>> > be
>> > > filled out but I don't know what values to put there. If the two get
>> > fixed,
>> > > it will hopefully be just 2 new failures along with 3 that pass.
>> > >
>> > >
>> > > > There is just fp-long-alu that is for sure a regression caused by new
>> > > > master code (some gallium changes). I don't know about the 3 others.
>> > > >
>> > > > It might be worth to re-test everything on your new branch with this
>> > > > patch reverted :
>> > > > nvfx: rewrite render temporaries code, also affecting 2D and resource
>> > code
>> > > >
>> > >
>> > > Here is the tree with the commit reverted:
>> > >
>> > > git://anongit.freedesktop.org/~mareko/mesa<http://anongit.freedesktop.org/%7Emareko/mesa>nvfx-next-6b-notemps
>> > >
>> > > It is compile-tested so if it does not work, there is nothing I can do
>> > about
>> > > it.
>> > >
>> > > -Marek
>> >
>> > I just tested the new tree nvfx-next-6b-notemps, I think we should go
>> > some commits before, because Luca removed the check in fbo setting
>> > between difference in bits between colour and depth/stencil buffer, and
>> > nv30 hw does not support that (they must be equal) and doing that
>> > simply hang the gpu.
>> >
>> > Commit 4787059263755fb92b2bb09ac71658d9b4cc9368 'nvfx: new 2D: add
>> > support for render temporaries' removed this check and fbo tests
>> > trigger the bug. Maybe Luca was planning to use temporaries to avoid
>> > this check, but unfortunately we do not know if he finished it or not.
>>
>> I do not want to guess here. I would like to hear something from Luca before
>> doing anything else with his code.
>
> It has been 3 months since latest Luca's sign, and I'm afraid it will
> be a while before it changes :-(.
>
> Marek, if you are still interested in merging stuff from nvfx-next-6b,
> I would like to propose up to commit
> 9a4c66b0d1963c4d90fccac41e7aa48105835857 included (as I said before,
> the following ones bring back nasty regression regarding fbo stuff,
> hanging the gpu hard).
>
> Luca did many fixes in his branch so it's really bad these ones are not
> merged back to master. Also, I don't feel like touching the nvfx
> backend in master till these fixes are merged.

I got busy with other things and then essentially lost interest;
furthermore, my nv40 is not even working right now.

As for the code, sure, feel free to make it work and merge it :)
The new temporary code did indeed screw things up, and I think it also
had other stuff mixed in that I didn't factor out.
However, the old temporary code is wrong because the temporary is
per-surface, while it should be attached to the resource, so that
multiple surfaces, and direct use of the resource itself, works
properly.

nv40 should support having mismatching color/depth as long as both are
linear and not swizzled.
I'm not sure if that is the case on nv30 or if there the restriction
applies to both cases.

There are also two branches starting with "RFC" in mesa git that add
correct nv30 ARB_texture_rectangle and correct glsl support, which
require minor Gallium changes but for which IIRC I never got answers
back from Gallium maintainers.

There should also be code in other branches to add control flow for
nv40 fragment programs (and perhaps other features I don't remember
right now).
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Lucas Stach]

Am Samstag, den 24.07.2010, 01:52 +0200 schrieb Marek Olšák: 
> 
> 9a4c66b0d1963c4d90fccac41e7aa48105835857 doesn't compile, so I went
> one commit back.
> 
> It's here for testing:
> git://anongit.freedesktop.org/~mareko/mesa nvfx-new
> 
> Please let me know if it works.
> 
> -Marek

Hi,

I did a short test with glxdragon and openarena. With this basic stuff I
see no regressions compared with the current mesa master.

--Lucas 


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Patrice Mandin]

Le Sat, 24 Jul 2010 01:52:57 +0200
Marek Olšák <maraeo@gmail.com> a écrit:

> > Marek, if you are still interested in merging stuff from nvfx-next-6b,
> > I would like to propose up to commit
> > 9a4c66b0d1963c4d90fccac41e7aa48105835857 included (as I said before,
> > the following ones bring back nasty regression regarding fbo stuff,
> > hanging the gpu hard).
> >
> 
> 9a4c66b0d1963c4d90fccac41e7aa48105835857 doesn't compile, so I went one
> commit back.
> 
> It's here for testing:
> git://anongit.freedesktop.org/~mareko/mesa nvfx-new
> 
> Please let me know if it works.

I found 2 regressions:

- xbmc not starting anymore (stuck at start), due to commit
ab434f6b7641a64d30725a9ac24929240362d466 (glx: Use _Xglobal_lock for
protecting extension display list) according to git bisect.
Current master does not have this problem, so some investigation needed
(as xbmc triggers some errors on the gpu even there).

- Textures not properly setup in some programs (alien arena, ut 2004
demo) i.e. shown non swizzled when they should be swizzled. git bisect
did not show anything till the merge between master and nvfx-next, so
once again, some investigation needed.

I'll be in holidays soon, so I hope to have time to fix these.

-- 
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

"who writes the code, decides"


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nvfx

[Patrice Mandin]

Le Sat, 24 Jul 2010 15:34:06 +0200
Luca Barbieri <luca-Ukmtq+NC3rhBHFWNQifrYwC/G2K4zDHf@public.gmane.org> a écrit:

> I got busy with other things and then essentially lost interest;
> furthermore, my nv40 is not even working right now.
> 
> As for the code, sure, feel free to make it work and merge it :)
> The new temporary code did indeed screw things up, and I think it also
> had other stuff mixed in that I didn't factor out.
> However, the old temporary code is wrong because the temporary is
> per-surface, while it should be attached to the resource, so that
> multiple surfaces, and direct use of the resource itself, works
> properly.
> 
> nv40 should support having mismatching color/depth as long as both are
> linear and not swizzled.
> I'm not sure if that is the case on nv30 or if there the restriction
> applies to both cases.
> 
> There are also two branches starting with "RFC" in mesa git that add
> correct nv30 ARB_texture_rectangle and correct glsl support, which
> require minor Gallium changes but for which IIRC I never got answers
> back from Gallium maintainers.
> 
> There should also be code in other branches to add control flow for
> nv40 fragment programs (and perhaps other features I don't remember
> right now).

Hello Luca,

Happy to get some news from you, and a bit sad you can not continue to
work on it.

Thanks for this report. At last, we know in which state is the work you
left.

-- 
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

"who writes the code, decides"