Re: [Nouveau] NV50 compute support questions

[Hans de Goede]

Hi,

On 02-12-15 19:33, Samuel Pitoiset wrote:



On 12/02/2015 04:34 PM, Hans de Goede wrote:

On 01-12-15, Samuel Pitoiset wrote:

 >>> Ok, here is a MMT trace of vectorAdd:
 >>>
 >>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz
 >>
 >> Hi Hans,
 >>
 >> Thanks a lot.
 >
 > Well, I didn't know but Martin has a GK208...
 > I just tested the compute support on his card and ... it works without
 > any changes. :-)
 >
 > I'm sorry, I was sure the compute support didn't work on this chipset.

No need to be sorry because, ...

 > Feel free to test on your GK208 and report back if you have problems.

I've done that, and for me it does not work, if I try to enable compute
support like this:

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 461fcaa..ab4ea85 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -187,7 +187,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
enum pipe_cap param)
 case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
 case PIPE_CAP_COMPUTE:
-  return (class_3d <= NVE4_3D_CLASS) ? 1 : 0;
+  return 1;
 case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ?
1 : 0;

@@ -246,8 +246,6 @@ nvc0_screen_get_shader_param(struct pipe_screen
*pscreen, unsigned shader,
   return 0;
break;
 case PIPE_SHADER_COMPUTE:
-  if (class_3d > NVE4_3D_CLASS)
- return 0;
break;
 default:
return 0;
@@ -574,11 +572,10 @@ nvc0_screen_init_compute(struct nvc0_screen *screen)
 case 0xd0:
return nvc0_screen_compute_setup(screen, screen->base.pushbuf);
 case 0xe0:
-  return nve4_screen_compute_setup(screen, screen->base.pushbuf);
 case 0xf0:
 case 0x100:
 case 0x110:
-  return 0;
+  return nve4_screen_compute_setup(screen, screen->base.pushbuf);
 default:
return -1;
 }

Then as soon as I do startx (which starts gnome-shell) the machine
freezes. This is with mesa-master with the above changes on top.

X / gnome-shell will happily work of I do not call
nve4_screen_compute_setup()
but then test/trivial/compute fails with a null-ptr exception.

Do you perhaps have some extra patches in your tree, or am I just unlucky ?

I've tested this on both a 4.2 and a 4.4-rc3 kernel.


Hi,

My bad... I used the wrong card on reator (which is the REing machine of 
Martin). The primary card is a GK106 and the second one is the GK208. That 
doesn't explain why I did something wrong but heh? :-)

You are right. With those bits added locally, the compute support totally hangs 
the GPU on my GK208 (NV108), and a reboot is needed.

Please give a shot at this branch :
http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute

It fixes the initialization of the compute state and allows me to
launch 'test_input_global' (ie. ./compute 8) on my GK208 without
any dmesg fails. That's a good start but more patches are coming. :-)


This branch indeed works somewhat better, but things still hang on the

test_system_values compute test for me (this is the first test executed
I did not try the others). So this seems to need more work.

I've ordered a GTX740 (GK107) card, which should arrive soon, and
I'll be using that so I can (hopefully) focus on the llvm tgsi bits
again.


Btw, according to the trace you sent me, you have a GK208b (NV106).


Right, sorry I thought the differences between GK208 and GK208b would not 
matter.

Thanks for all the input / help!

Regards,

Hans


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

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #9 from Volker Lukas  ---
Hi doktor.yak,

at the time I encountered this bug, the Opensuse Linux 4.2.4 RPM was still
downloadable.

If you build linux-4.2.6.tar.xz from kernel.org via "make rpm" you should be
able to get a working kernel package. You can copy the
/boot/config-4.x-something to the kernel source directory to copy the build
configuration (rename it to ".config").

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #10 from doktor@gmail.com ---
Thanks for your answer.

Do you know if Suse did apply any patch on their version of the 4.2.4 kernel ?

Otherwise I'll follow your recommendation and compile a vanilla kernel. (with
"make oldconfig"-ing /proc/config.gz)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] NV50 compute support questions

[Samuel Pitoiset]

On 12/04/2015 10:12 AM, Hans de Goede wrote:

Hi,

On 04-12-15 09:54, Samuel Pitoiset wrote:



On 12/04/2015 09:45 AM, Hans de Goede wrote:





Please give a shot at this branch :
http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute

It fixes the initialization of the compute state and allows me to
launch 'test_input_global' (ie. ./compute 8) on my GK208 without
any dmesg fails. That's a good start but more patches are coming. :-)


This branch indeed works somewhat better, but things still hang on the

test_system_values compute test for me (this is the first test executed
I did not try the others). So this seems to need more work.


What about test_input_global? test_system_values doesn't work on my
side but it doesn't hang the GPU.


Yes that one works.


Could you please provide dmesg log?


[2.786631] nouveau :01:00.0: NVIDIA GK208B (b06070b1)
[2.914291] nouveau :01:00.0: bios: version 80.28.79.00.0b
[2.937909] nouveau :01:00.0: priv: HUB0: 086014  (1f70820c)
[2.937953] nouveau :01:00.0: fb: 1024 MiB DDR3
[3.623202] [TTM] Zone  kernel: Available graphics memory: 2010556 kiB
[3.623205] [TTM] Initializing pool allocator
[3.623241] [TTM] Initializing DMA pool allocator
[3.623440] nouveau :01:00.0: DRM: VRAM: 1024 MiB
[3.623442] nouveau :01:00.0: DRM: GART: 1048576 MiB
[3.623447] nouveau :01:00.0: DRM: TMDS table version 2.0
[3.623449] nouveau :01:00.0: DRM: DCB version 4.0
[3.623451] nouveau :01:00.0: DRM: DCB outp 00: 01000f02 00020030
[3.623454] nouveau :01:00.0: DRM: DCB outp 01: 02011f62 00020010
[3.623456] nouveau :01:00.0: DRM: DCB outp 02: 02022f10 
[3.623458] nouveau :01:00.0: DRM: DCB conn 00: 1031
[3.623460] nouveau :01:00.0: DRM: DCB conn 01: 2161
[3.623462] nouveau :01:00.0: DRM: DCB conn 02: 0200
[3.627283] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.627285] [drm] Driver supports precise vblank timestamp query.
[3.671871] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
[3.889940] nouveau :01:00.0: DRM: allocated 1920x1080 fb:
0x6, bo 88011905
[3.890952] fbcon: nouveaufb (fb0) is primary device
[4.132343] Console: switching to colour frame buffer device 240x67
[4.134930] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[4.141094] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0
on minor 0



[ 1713.421460] nouveau :01:00.0: gr: TRAP ch 6 [003fa32000
compute[21117]]
[ 1713.421471] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global
 [] warp 3000e [MEM_OUT_OF_BOUNDS]
[ 1713.441248] nouveau :01:00.0: gr: TRAP ch 6 [003fa32000
compute[21117]]
[ 1713.441260] nouveau :01:00.0: gr: GPC0/TPC0/MP trap: global
0004 [MULTIPLE_WARP_ERRORS] warp 20005 [MISALIGNED_PC]
[ 1713.441265] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global
0004 [MULTIPLE_WARP_ERRORS] warp 20005 [MISALIGNED_PC]
[ 1717.773839] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1717.773848] nouveau :01:00.0: fifo: sw engine fault on channel 2,
recovering...
[ 1719.776529] nouveau :01:00.0: fifo: runlist 0 update timeout
[ 1722.068923] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1726.363660] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1730.658395] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1734.951720] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1739.241861] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1743.532005] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1747.826728] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1752.121462] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1756.416200] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1760.710930] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1765.005663] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1769.300396] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1773.595135] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1777.889863] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1782.184598] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1786.479328] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1789.730020] nouveau :01:00.0: compute[21117]: failed to idle
channel 6 [compute[21117]]
[ 1790.774060] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1791.729963] nouveau :01:00.0: timeout at
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c:47/gk104_fifo_gpfifo_kick()!

[ 1791.729966] nouveau :01:00.0: fifo: channel 6 [compute[21117]]
kick timeout
[ 1791.729973] nouveau: compute[21117]::a06f: detach gr
failed, -16
[ 1791.731401] nouveau :01:00.0: fifo: SCHED_ERROR 0d []
[ 1793.731275] nouveau 

Re: [Nouveau] NV50 compute support questions

[Hans de Goede]

Hi,

On 04-12-15 09:54, Samuel Pitoiset wrote:



On 12/04/2015 09:45 AM, Hans de Goede wrote:





Please give a shot at this branch :
http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute

It fixes the initialization of the compute state and allows me to
launch 'test_input_global' (ie. ./compute 8) on my GK208 without
any dmesg fails. That's a good start but more patches are coming. :-)


This branch indeed works somewhat better, but things still hang on the

test_system_values compute test for me (this is the first test executed
I did not try the others). So this seems to need more work.


What about test_input_global? test_system_values doesn't work on my side but it 
doesn't hang the GPU.


Yes that one works.


Could you please provide dmesg log?


[2.786631] nouveau :01:00.0: NVIDIA GK208B (b06070b1)
[2.914291] nouveau :01:00.0: bios: version 80.28.79.00.0b
[2.937909] nouveau :01:00.0: priv: HUB0: 086014  (1f70820c)
[2.937953] nouveau :01:00.0: fb: 1024 MiB DDR3
[3.623202] [TTM] Zone  kernel: Available graphics memory: 2010556 kiB
[3.623205] [TTM] Initializing pool allocator
[3.623241] [TTM] Initializing DMA pool allocator
[3.623440] nouveau :01:00.0: DRM: VRAM: 1024 MiB
[3.623442] nouveau :01:00.0: DRM: GART: 1048576 MiB
[3.623447] nouveau :01:00.0: DRM: TMDS table version 2.0
[3.623449] nouveau :01:00.0: DRM: DCB version 4.0
[3.623451] nouveau :01:00.0: DRM: DCB outp 00: 01000f02 00020030
[3.623454] nouveau :01:00.0: DRM: DCB outp 01: 02011f62 00020010
[3.623456] nouveau :01:00.0: DRM: DCB outp 02: 02022f10 
[3.623458] nouveau :01:00.0: DRM: DCB conn 00: 1031
[3.623460] nouveau :01:00.0: DRM: DCB conn 01: 2161
[3.623462] nouveau :01:00.0: DRM: DCB conn 02: 0200
[3.627283] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.627285] [drm] Driver supports precise vblank timestamp query.
[3.671871] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
[3.889940] nouveau :01:00.0: DRM: allocated 1920x1080 fb: 0x6, bo 
88011905
[3.890952] fbcon: nouveaufb (fb0) is primary device
[4.132343] Console: switching to colour frame buffer device 240x67
[4.134930] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[4.141094] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on 
minor 0



[ 1713.421460] nouveau :01:00.0: gr: TRAP ch 6 [003fa32000 compute[21117]]
[ 1713.421471] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global  [] 
warp 3000e [MEM_OUT_OF_BOUNDS]
[ 1713.441248] nouveau :01:00.0: gr: TRAP ch 6 [003fa32000 compute[21117]]
[ 1713.441260] nouveau :01:00.0: gr: GPC0/TPC0/MP trap: global 0004 
[MULTIPLE_WARP_ERRORS] warp 20005 [MISALIGNED_PC]
[ 1713.441265] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global 0004 
[MULTIPLE_WARP_ERRORS] warp 20005 [MISALIGNED_PC]
[ 1717.773839] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1717.773848] nouveau :01:00.0: fifo: sw engine fault on channel 2, 
recovering...
[ 1719.776529] nouveau :01:00.0: fifo: runlist 0 update timeout
[ 1722.068923] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1726.363660] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1730.658395] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1734.951720] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1739.241861] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1743.532005] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1747.826728] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1752.121462] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1756.416200] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1760.710930] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1765.005663] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1769.300396] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1773.595135] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1777.889863] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1782.184598] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1786.479328] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1789.730020] nouveau :01:00.0: compute[21117]: failed to idle channel 6 
[compute[21117]]
[ 1790.774060] nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
[ 1791.729963] nouveau :01:00.0: timeout at 
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c:47/gk104_fifo_gpfifo_kick()!
[ 1791.729966] nouveau :01:00.0: fifo: channel 6 [compute[21117]] kick 
timeout
[ 1791.729973] nouveau: compute[21117]::a06f: detach gr failed, -16
[ 1791.731401] nouveau :01:00.0: fifo: SCHED_ERROR 0d []
[ 1793.731275] nouveau :01:00.0: timeout at 

[Nouveau] FC22 verus FC23

[Craig Garner]

I have a quad display set up.  It is working perfectly under FC22, but
bombs on FC23.  I wish I had more information for you, but I had to get
this machine back up and running.

Not only does the quad head not work, the one working head was operating at
1280x1024 versus 1920x1080.

I tried doing a fresh install of FC23 and an upgrade from FC22 to FC23.  It
did not work in either situation.  So, I am back to FC22 until it really
sounds like it will work at some point in time and I can do an upgrade or
fresh install.

It has a G520 and a G730 running in it.

Thank you,

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

Re: [Nouveau] NV50 compute support questions

[Samuel Pitoiset]

On 12/04/2015 09:45 AM, Hans de Goede wrote:

Hi,

On 02-12-15 19:33, Samuel Pitoiset wrote:



On 12/02/2015 04:34 PM, Hans de Goede wrote:

On 01-12-15, Samuel Pitoiset wrote:

 >>> Ok, here is a MMT trace of vectorAdd:
 >>>
 >>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz
 >>
 >> Hi Hans,
 >>
 >> Thanks a lot.
 >
 > Well, I didn't know but Martin has a GK208...
 > I just tested the compute support on his card and ... it works
without
 > any changes. :-)
 >
 > I'm sorry, I was sure the compute support didn't work on this
chipset.

No need to be sorry because, ...

 > Feel free to test on your GK208 and report back if you have problems.

I've done that, and for me it does not work, if I try to enable compute
support like this:

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 461fcaa..ab4ea85 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -187,7 +187,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen,
enum pipe_cap param)
 case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
 case PIPE_CAP_COMPUTE:
-  return (class_3d <= NVE4_3D_CLASS) ? 1 : 0;
+  return 1;
 case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ?
1 : 0;

@@ -246,8 +246,6 @@ nvc0_screen_get_shader_param(struct pipe_screen
*pscreen, unsigned shader,
   return 0;
break;
 case PIPE_SHADER_COMPUTE:
-  if (class_3d > NVE4_3D_CLASS)
- return 0;
break;
 default:
return 0;
@@ -574,11 +572,10 @@ nvc0_screen_init_compute(struct nvc0_screen
*screen)
 case 0xd0:
return nvc0_screen_compute_setup(screen, screen->base.pushbuf);
 case 0xe0:
-  return nve4_screen_compute_setup(screen, screen->base.pushbuf);
 case 0xf0:
 case 0x100:
 case 0x110:
-  return 0;
+  return nve4_screen_compute_setup(screen, screen->base.pushbuf);
 default:
return -1;
 }

Then as soon as I do startx (which starts gnome-shell) the machine
freezes. This is with mesa-master with the above changes on top.

X / gnome-shell will happily work of I do not call
nve4_screen_compute_setup()
but then test/trivial/compute fails with a null-ptr exception.

Do you perhaps have some extra patches in your tree, or am I just
unlucky ?

I've tested this on both a 4.2 and a 4.4-rc3 kernel.


Hi,

My bad... I used the wrong card on reator (which is the REing machine
of Martin). The primary card is a GK106 and the second one is the
GK208. That doesn't explain why I did something wrong but heh? :-)

You are right. With those bits added locally, the compute support
totally hangs the GPU on my GK208 (NV108), and a reboot is needed.

Please give a shot at this branch :
http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute

It fixes the initialization of the compute state and allows me to
launch 'test_input_global' (ie. ./compute 8) on my GK208 without
any dmesg fails. That's a good start but more patches are coming. :-)


This branch indeed works somewhat better, but things still hang on the

test_system_values compute test for me (this is the first test executed
I did not try the others). So this seems to need more work.


What about test_input_global? test_system_values doesn't work on my side 
but it doesn't hang the GPU. Could you please provide dmesg log?




I've ordered a GTX740 (GK107) card, which should arrive soon, and
I'll be using that so I can (hopefully) focus on the llvm tgsi bits
again.


Yeah, GK107 will do the job. :-)




Btw, according to the trace you sent me, you have a GK208b (NV106).


Right, sorry I thought the differences between GK208 and GK208b would
not matter.


I don't know exactly the differences between these two chipsets but 
since test_system_values hangs your GPU and not mine, I think they are some.




Thanks for all the input / help!

Regards,

Hans




--
-Samuel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #38 from Gabriele Svelto  ---
Yes, the emulator seems to be calling GL commands from multiple threads, or at
least the traces I got seemed to have different thread identifiers for
different commands.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #39 from Ilia Mirkin  ---
(In reply to Gabriele Svelto from comment #38)
> Yes, the emulator seems to be calling GL commands from multiple threads, or
> at least the traces I got seemed to have different thread identifiers for
> different commands.

Unfortunately nouveau doesn't protect against concurrency and when multiple
threads call into the GL simultaneously, will fall flat on its face.

Fixing this is on my todo list... but my todo list is long, and this is a
tricky task to do so as not to pessimize the 99.99% use-case of single-threaded
GL usage.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #35 from Gabriele Svelto  ---
I've updated mesa again and running from the current master I encounter the
segfault again. This time though this is the only message that pops up in the
kernel log:

[ 4684.326211] emulator-x86[19034]: segfault at 4 ip f5f49403 sp
ac6fc660 error 4 in libdrm_nouveau.so.2.0.0[f5f46000+7000]

I'm wondering if running a master mesa with a non-master libdrm is supported at
all.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #37 from Ilia Mirkin  ---
(In reply to Gabriele Svelto from comment #35)
> I've updated mesa again and running from the current master I encounter the
> segfault again. This time though this is the only message that pops up in
> the kernel log:
> 
> [ 4684.326211] emulator-x86[19034]: segfault at 4 ip f5f49403 sp
> ac6fc660 error 4 in libdrm_nouveau.so.2.0.0[f5f46000+7000]
> 
> I'm wondering if running a master mesa with a non-master libdrm is supported
> at all.

Most likely the emulator is doing GL stuff from different threads, which
doesn't work with nouveau. Sorry :(

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92438] Segfault in pushbuf_kref when running the android emulator (qemu) on nv50

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92438

--- Comment #36 from Emil Velikov  ---
(In reply to Gabriele Svelto from comment #35)
> I've updated mesa again and running from the current master I encounter the
> segfault again. This time though this is the only message that pops up in
> the kernel log:
> 
> [ 4684.326211] emulator-x86[19034]: segfault at 4 ip f5f49403 sp
> ac6fc660 error 4 in libdrm_nouveau.so.2.0.0[f5f46000+7000]
> 
> I'm wondering if running a master mesa with a non-master libdrm is supported
> at all.

If it build again given libdrm{,-nouveau} version it should work. Bugs on the
other hand are something that occasionally exist.

Which version (sha) is the above libdrm-nouveau ? Can you disassemble at the
given offset ?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 93250] New: After VGA change monitor do not detects properly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93250

Bug ID: 93250
   Summary: After VGA change monitor do not detects properly
   Product: xorg
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: vou...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 120354
  --> https://bugs.freedesktop.org/attachment.cgi?id=120354=edit
Kernel log

Hello!

I've changed VGA from Geforce GTX 470 to 980.
My distro is openSUSE 13.2. From the moment of installation I've used nouveau
driver and it worked very well. I have DELL U2415 monitor attached via HDMI.
Since the switch the monitor is detected as default and the resolution is set
to 1024X768.
Using the 'nomodeset' parameter can rise the resolution to 1600X1200, but
monitor is still not detected, and no native resolution can be picked.

Thank you in advance,
Piotr.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 93250] After VGA change monitor do not detects properly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93250

Ilia Mirkin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Ilia Mirkin  ---
[0.00] Linux version 3.16.7-29-desktop (geeko@buildhost) (gcc version
4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP PREEMPT
Fri Oct 23 00:46:04 UTC 2015 (6be6a97)

I believe nouveau gained modesetting support for GM20x in Kernel 3.19.
Additional fixes were made in later kernel versions too. Feel free to reopen if
it doesn't work with kernel 4.2 or later.

Note that 'nomodeset' completely prevents nouveau from doing anything at all,
so you end up using vesa or whatnot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 92892] [NVA8] KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92892

--- Comment #11 from Takashi Iwai  ---
(In reply to doktor.yak from comment #10)
> Thanks for your answer.
> 
> Do you know if Suse did apply any patch on their version of the 4.2.4 kernel
> ?

Nothing about nouveau.

> Otherwise I'll follow your recommendation and compile a vanilla kernel.
> (with "make oldconfig"-ing /proc/config.gz)

It's anyway better to compile by yourself for excluding any subtle differences.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 93254] [NVA5] The Long Dark (game) is very slow because of "kernel rejected pushbuf" messages in log files

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93254

--- Comment #2 from Alexander Schlarb  ---
Created attachment 120360
  --> https://bugs.freedesktop.org/attachment.cgi?id=120360=edit
Kernel log

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 93254] [NVA5] The Long Dark (game) is very slow because of "kernel rejected pushbuf" messages in log files

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93254

--- Comment #3 from Alexander Schlarb  ---
Created attachment 120361
  --> https://bugs.freedesktop.org/attachment.cgi?id=120361=edit
X11 Server log

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 93254] [NVA5] The Long Dark (game) is very slow because of "kernel rejected pushbuf" messages in log files

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93254

--- Comment #1 from Alexander Schlarb  ---
Created attachment 120359
  --> https://bugs.freedesktop.org/attachment.cgi?id=120359=edit
Complete log file (compressed)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 93254] [NVA5] The Long Dark (game) is very slow because of "kernel rejected pushbuf" messages in log files

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93254

--- Comment #4 from Ilia Mirkin  ---
Interesting... so this may actually be a legit situation of "gpu not processing
pushbufs fast enough" and we run out of IB space. For some reason each pushbuf
has a very small quantity of commands... oh, I see. It's just a ton of
small-ish indexed draws, each of which ends up going through
nouveau_pushbuf_data() which in turn causes a new IB slot to be used up.

We need to have some way to figure out how many IB slots are open... or
throttle pushbuf submission or... something.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 93254] New: [NVA5] The Long Dark (game) is very slow because of "kernel rejected pushbuf" messages in log files

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93254

Bug ID: 93254
   Summary: [NVA5] The Long Dark (game) is very slow because of
"kernel rejected pushbuf" messages in log files
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: alexander...@xmine128.tk
QA Contact: nouveau@lists.freedesktop.org

Created attachment 120358
  --> https://bugs.freedesktop.org/attachment.cgi?id=120358=edit
First "kernel rejected pushbuf" error in log file

Kernel: Linux 4.3 (snapshot from 2015-11-04)
Mesa: 11.0.2
nouveau X11 driver: 1.0.11
Platform: Sony VPCF12S1E with NVidiaGT216M (GForce GT 330M)
System: Debian testing based

Starting the game works fine (although it is somewhat slower than with NVidia's
driver), but once you launch the actual game Unity starts logging up to 1GB/min
worth of "kernel rejected pushbuf" logs into the
"~/.config/unity3d/Hinterland/The Long Dark/Player.log" log file. Making that
file (and it's containing directory) read-only I could verify that the game
runs at acceptable frame rates and without noticeable glitches most of the
time. Sometimes however, some textures disappear and it hangs for several
seconds before resuming.

Steps to reproduce:

 1) Purchase and download "The Long Dark" from Steam[1]
 2) Navigate to "~/.local/share/Steam/steamapps/common/TheLongDark" (on the
console or a file browser)
 3) Launch the "tld.x86_64" file[2]
 4) Press any key to move past the disclaimer screen
 5) Select "Sandbox" from the main menu[3]
 6) Start a "New" game or "Continue" a previous survival trip
 7) Wait for the actual game to load
 8) Observe extreme slowness while the disk I/O is a 100%

"Step 8" does not happen with NVidia binary drivers and the game is quite
playable.

See "Player.log.head" for first "kernel rejected pushbuf" error.
The corresponding `dmesg` message is:

nouveau :01:00.0: tld.x86_64[28285]: nv50cal_space: -16

If you tell me what to do for debugging this, I'll definitely help as much as I
can in fixing this issue!
(Including kernel patches, traces, etc.)

Notes:
 1. I'm willing to donate a copy of the game to one established Nouveau
contributor
 2. The game cannot be launched from Steam when using recent versions of Open
source drivers due to https://github.com/ValveSoftware/steam-runtime/issues/34
 3. Due to the game being alpha right now the "Story"-mode has not been
released yet – this shouldn't matter however

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] My Issue

[Craig Garner]

I run quad heads 2 graphic cards..They are NVidia chipset cards.
Everything worked perfectly.  Then I upgraded to FC23 and eveything goes
wrong.  Only 1 monitor comes up at half the resolution of the monitor.  I
tried a fresh install of FC23 with the same effect.  I wish I could tell
you more, but I have quite a bit going on right now and had to get my
station running agin.

The cards are GF 8600 and GT 830.  They were working so I do not think the
actual cards are the issue.  It has to be something that changed between
f22 and f23 :(
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] My Issue

[Ilia Mirkin]

In order to make any progress on the issue you'll need to obtain logs,
both from working and non-working setups. Based on your description,
it sounds like nouveau isn't loading properly on FC23, which can
happen for a number of reasons (and which the logs should make
apparent). The reason you get one monitor at low resolution is, most
likely, that it's using vesa (but again, impossible to tell without
logs).

Specifically I'd be looking for dmesg and xorg log from the FC23 boot.

Cheers,

  -ilia


On Fri, Dec 4, 2015 at 8:14 PM, Craig Garner  wrote:
> I run quad heads 2 graphic cards..They are NVidia chipset cards.  Everything
> worked perfectly.  Then I upgraded to FC23 and eveything goes wrong.  Only 1
> monitor comes up at half the resolution of the monitor.  I tried a fresh
> install of FC23 with the same effect.  I wish I could tell you more, but I
> have quite a bit going on right now and had to get my station running agin.
>
> The cards are GF 8600 and GT 830.  They were working so I do not think the
> actual cards are the issue.  It has to be something that changed between f22
> and f23 :(
>
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau