Re: [Nouveau] Progress on nv46 vblank bug

p.s. I'm starting to think that it may eb best to just disable vblank for nv46 hardware in the ddx and be done with it, any opinions on this ? ___ Nouveau mailing list Nouveau@lists.freedesktop.org

Re: [Nouveau] Progress on nv46 vblank bug

Hi, On 16-06-15 16:02, Ilia Mirkin wrote: On Tue, Jun 16, 2015 at 5:34 AM, Hans de Goede hdego...@redhat.com wrote: So any hints how to mvoe forward with this are appreciated. I can only say what I would do... forget about trying to quantify which cases work and which don't, just take

[Nouveau] Progress on nv46 vblank bug

Hi All, So I've been working~w banging my head against the nv46 vblank bug again and I've been finding out some interesting things. This is all using the latest kernel + ddx + mesa code. All of this was tested with *cold* (power removed from wall outlet for 20 seconds) boots in between the

Re: [Nouveau] Self introduction Hans de Goede

Hi, On 26-05-15 09:41, Martin Peres wrote: On 26/05/15 10:29, Hans de Goede wrote: Hi All, Since I will be working on nouveau pretty much starting today I thought it would be good to write a quick self introduction. I'm an FOSS enthusiast / developer since 1996. I've written (and still

[Nouveau] Self introduction Hans de Goede

Hi All, Since I will be working on nouveau pretty much starting today I thought it would be good to write a quick self introduction. I'm an FOSS enthusiast / developer since 1996. I've written (and still maintain) various hwmon drivers, various USB webcam drivers, libv4l and libgphoto camlibs

Re: [Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

Hi, On 28-07-15 09:26, Ben Skeggs wrote: On 28 July 2015 at 01:52, Hans de Goede hdego...@redhat.com wrote: Hi, On 24-07-15 04:32, Ben Skeggs wrote: On 24 July 2015 at 01:20, Hans de Goede hdego...@redhat.com wrote: MSI interrupts appear to not work for nv46 based cards. Change the mc

[Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

Hi Maarten, xf86-video-nouveau causes a garbled display when running gnome-shell on nv4x (tested with nv43 and nv46) since this commit: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e7289f25a342a457952b9b0e539c2f0b81d99 I've seen some discussion about issues caused by

Re: [Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

Hi, On 27-07-15 17:52, Hans de Goede wrote: Slightly offtopic: I decided to be bold and try gnome-shell on the nv46 with msi disabled, which sofar was a guaranteed way to freeze the system, and it now works somewhat (latest kernel, ddx and mesa). I see something which shows horizontal lines

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion is that this is due to the lack of PUSH_KICK in the *Done exa handlers -- works fine with DRI2, but DRI3 has no synchronization and so

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

Hi, On 11-08-15 14:21, Ilia Mirkin wrote: On Mon, Aug 10, 2015 at 8:47 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 20:09, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon

[Nouveau] [PATCH mesa] nv30: Fix creation of scanout buffers

are allocated by mesa, rather then by the ddx, and the wrong stride of these buffers was causing the garbled display. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/gallium/drivers/nouveau/nv30/nv30_miptree.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/gallium/drivers

Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x

Hi, On 03-08-15 20:09, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW

Re: [Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

Hi, On 24-07-15 04:32, Ben Skeggs wrote: On 24 July 2015 at 01:20, Hans de Goede hdego...@redhat.com wrote: MSI interrupts appear to not work for nv46 based cards. Change the mc subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is identical to the nv44 mc code except

Re: [Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

Hi, On 24-07-15 04:32, Ben Skeggs wrote: On 24 July 2015 at 01:20, Hans de Goede hdego...@redhat.com wrote: MSI interrupts appear to not work for nv46 based cards. Change the mc subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is identical to the nv44 mc code except

[Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

=90435 Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c index c630136

Re: [Nouveau] [PATCH mesa 0/5] nouveau: codegen: Make use of double immediates

Hi, On 07-11-15 01:59, Ilia Mirkin wrote: Hi Hans, All pushed. I made a few additional fixes and improvement to fp64 immediate handling along the way, but all your commits were fine as-is. (Except that they enabled fp64 immediates on nv50 implicitly which is wrong -- there are no

Re: [Nouveau] [Mesa-dev] llvm TGSI backend (WIP) questions

Hi, On 13-11-15 19:51, Tom Stellard wrote: On Fri, Nov 13, 2015 at 02:46:52PM +0100, Hans de Goede wrote: Hi All, So as discussed I've started working on a TGSI backend for llvm to use as a way to get compute going on nouveau (and other gpu-s). I'm still learning all the ins and outs of llvm

[Nouveau] [PATCH mesa 2/5] nouveau: codegen: emit_gm107: Add support for double immediates

Add support for encoding double immediates (up to 20 bits of precision) into the generated gm107 machine-code. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

[Nouveau] [PATCH mesa 4/5] nouveau: codegen: Teach insnCanLoad about double immediates

.50 (8) Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../nouveau/codegen/nv50_ir_target_nvc0.cpp| 25 -- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp b/src/gallium/drivers

[Nouveau] [PATCH mesa 0/5] nouveau: codegen: Make use of double immediates

Hi All, This series implements using double immediates in the nouveau codegen code. This turns the following (nvc0) code: 1: mov u32 $r2 0x (8) 2: mov u32 $r3 0x3fe0 (8) 3: add f64 $r0d $r0d $r2d (8) Into: 1: add f64 $r0d $r0d 0.50 (8) This has been

[Nouveau] [PATCH mesa 3/5] nouveau: codegen: Add support for merge-s to the ConstantFolding pass

This allows later passes like LoadPropagation to properly deal with 64 bit immediates. If the new 64 bit load this introduces does not get optimized away then split64BitOpPostRA() will split this into 2 instructions again. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/g

[Nouveau] [PATCH mesa 5/5] nouveau: codegen: Add support for 64bit immediates to checkSwapSrc01

Now that we support 64 bit immediates in insnCanLoad, we need to swap 64 bit immediate sources too for optimal effect. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 11 ++- 1 file changed, 6 insertions(+), 5 del

[Nouveau] [PATCH mesa 1/5] nouveau: codegen: emit_nvc0: Add support for double immediates

Add support for encoding double immediates (up to 20 bits of precision) into the generated nvc0 machine-code. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 8 1 file changed, 8 insertions(+) diff --git a/src/g

[Nouveau] [PATCH envytools] envydis: gk110: Add support for dadd with an immediate src

o the same using nvdisasm and works properly on an actual gpu. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- envydis/gk110.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/envydis/gk110.c b/envydis/gk110.c index 9af18e1..4790533 100644 --- a/envydis/gk110.c +++ b/envydis/gk

[Nouveau] llvm TGSI backend (WIP) questions

Hi All, So as discussed I've started working on a TGSI backend for llvm to use as a way to get compute going on nouveau (and other gpu-s). I'm still learning all the ins and outs of llvm so I do not have much to show yet. I've rebased Francisco's (curro's) latest version on top of llvm trunk,

[Nouveau] gallium state tracker calls calloc for 0 sizes arrays ?

Hi All, While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089 I made a apitrace recording of the a single slide transition animation, and since I suspected memory corruption replayed it using ElectrFence + glretrace, this finds a 0 sized array allocation at

Re: [Nouveau] [Mesa-dev] gallium state tracker calls calloc for 0 sizes arrays ?

Hi, On 27-08-15 15:46, Marek Olšák wrote: On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede hdego...@redhat.com wrote: Hi All, While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089 I made a apitrace recording of the a single slide transition animation, and since I suspected

[Nouveau] nv3x libreoffice impress opengl animations not working

Hi, On 27-08-15 20:19, Ilia Mirkin wrote: On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher alexdeuc...@gmail.com wrote: snip 2) Since the glretrace does work outside of libreoffice impress, I think it may have something to do with the visual chosen by libreoffice impress, is there an easy way

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

questions, 1 has been answered the other not. Note I've updated the subject to reflect this. Regards, Hans Marek On Fri, Aug 28, 2015 at 10:54 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 27-08-15 20:19, Ilia Mirkin wrote: On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher alexdeuc

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

Hi, On 28-08-15 11:02, Ilia Mirkin wrote: On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 27-08-15 20:19, Ilia Mirkin wrote: On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: 2) Since the glretrace does

Re: [Nouveau] [PATCH mesa 0/4] nv30: Various fixes

Hi, On 03-09-15 19:14, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi All, Here is a bunch of fixes for nv30 cards, the first patch is a resend of a patch I send a while back. AFAICT that one is ready for merging, but it is not entirely

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

Hi, On 03-09-15 19:36, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 02-09-15 16:44, Ilia Mirkin wrote: On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi Ilia Of course I don't really se

Re: [Nouveau] [PATCH mesa 4/4] nv30: Disable msaa on nv4x because it causes gpu lockups

Hi, On 03-09-15 19:33, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdego...@redhat.com> wrote: On nv4x with a msaa visual after a while the gpu locks up, attach gdb to impress shows it is hanging waiting for a fence which never comes. Killing ooimpress at this

[Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?

Hi All, I've recently acquired a nvs280 card, which is a nv34 gpu based card with a pci-e bridge on the card, this way I can test nv3x problems without needing an agp motherboard. One thing which stands out with this card is that it drivers my dvi lcd monitor at 1680x1050 instead of its native

Re: [Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x

Hi, On 03-09-15 19:32, Ilia Mirkin wrote: On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdego...@redhat.com> wrote: On nv3x we will likely end up using the cpu to do color resolving for msaa blits. Disable msaa on these cards so that we do not end up using the cpu. Actually the CPU fa

Re: [Nouveau] [PATCH mesa 2/3] nv30: Fix color resolving for nv3x cards

some more objective (ahem) tests on nv4x and get back to you on this. Regards, Hans On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede <hdego...@redhat.com> wrote: We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the

Re: [Nouveau] [PATCH mesa 3/3] nv30: Disable msaa for now because it causes lockups

Hi, On 07-09-15 22:00, Ilia Mirkin wrote: On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede <hdego...@redhat.com> wrote: msaa use on nv30 may trigger a (mesa?) bug where dmesg says: [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate [ 1197.850648] nouveau E[soffice.bi

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

Hi Ilia On 31-08-15 18:30, Ilia Mirkin wrote: On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdego...@redhat.com> wrote: Interestingly enough nv30_screen_get_param returns 0 for PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET And this hack: --- a/src/gallium/d

[Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x

On nv3x we will likely end up using the cpu to do color resolving for msaa blits. Disable msaa on these cards so that we do not end up using the cpu. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 12 ++-- 1 file chang

[Nouveau] [PATCH mesa 4/4] nv30: Disable msaa on nv4x because it causes gpu lockups

investigation, but for now disable msaa because no msaa is better then crashing the system. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouvea

[Nouveau] [PATCH mesa 2/4] nv30: Implement color resolve for msaa

Note this is not ideal. Since the sifm can only do source sizes upto 1024x1024 we end up using the blitter on nv4x, which is not that fast. And on nv3x we end up using the cpu which is really slow. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouvea

[Nouveau] [PATCH mesa 1/4] nv30: Fix creation of scanout buffers

ut buffers are allocated by mesa, rather then by the ddx, and the wrong stride of these buffers was causing the garbled display. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_miptree.c | 10 ++ 1 file changed, 10 insertions(+) diff --g

[Nouveau] [PATCH mesa 0/4] nv30: Various fixes

Hi All, Here is a bunch of fixes for nv30 cards, the first patch is a resend of a patch I send a while back. AFAICT that one is ready for merging, but it is not entirely clear to me what the process is for getting (nouveau) mesa patches merged. Should I request commit rights, and push my own

Re: [Nouveau] nv3x libreoffice impress opengl animations not working

Hi, On 02-09-15 16:44, Ilia Mirkin wrote: On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi Ilia Of course I don't really see how MS can work at all with nv30 since it doesn't support a resolve step: if (info.src.resource->nr_sa

[Nouveau] [PATCH mesa 3/3] nv30: Disable msaa for now because it causes lockups

and nv4x cards. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 17 + 1 file changed, 17 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 7

[Nouveau] [PATCH mesa 1/3] nv30: Fix max width / height checks in nv30 sifm code

The sifm object has a limit of 1024x1024 for its input size and 2048x2048 for its output. The code checking this was trying to be clever resulting in it seeing a surface of e.g 1024x256 being outside of the input size limit. This commit fixes this. Signed-off-by: Hans de Goede <hd

[Nouveau] [PATCH mesa 2/3] nv30: Fix color resolving for nv3x cards

We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the sources and dest surfaces in to tiles which match the constraints of the sifm object, so that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede

Re: [Nouveau] [PATCH mesa 2/3] nv30: Fix color resolving for nv3x cards

Hi, On 08-09-15 09:53, Hans de Goede wrote: Hi, On 07-09-15 21:55, Ilia Mirkin wrote: May I ask why you're doing 512x512 instead of 1024x1024? These are already scaled up coordinates, so 1024x1024 should work no? Or is it because of the seams on the edges? Do those not also appear

[Nouveau] [PATCH mesa v2 2/2] nv30: Disable msaa unless requested from the env by NV30_MAX_MSAA

[3785]] validate: -12 Because we are running out of video memory, after which the program using the msaa visual freezes, and eventually the entire system freezes. To work around this we do not allow msaa visauls by default and allow the user to override this via NV30_MAX_MSAA. Signed-off-by: Hans de

[Nouveau] [PATCH mesa v2 1/2] nv30: Fix color resolving for nv3x cards

We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the sources and dest surfaces in to tiles which match the constraints of the sifm object, so that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede

Re: [Nouveau] [PATCH] bios: fix OF loading

Hi, On 02-10-15 05:41, Ilia Mirkin wrote: As someone who has recently started following nouveau I must say that it would greatly help me (and likely others) if patches likes this would come with a somewhat more descriptive commit message. Otherwise keep up the good work! Regards, Hans

Re: [Nouveau] [PATCH] bios: fix OF loading

Hi, On 02-10-15 09:26, Ilia Mirkin wrote: On Fri, Oct 2, 2015 at 3:18 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 02-10-15 05:41, Ilia Mirkin wrote: As someone who has recently started following nouveau I must say that it would greatly help me (and likely others) if patches

Re: [Nouveau] [PATCH] bios: fix OF loading

Hi, On 02-10-15 09:38, Ilia Mirkin wrote: On Fri, Oct 2, 2015 at 3:35 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 02-10-15 09:26, Ilia Mirkin wrote: On Fri, Oct 2, 2015 at 3:18 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 02-10-15 05:41, Ilia

Re: [Nouveau] NV50 compute support questions

Hi On 04-12-15 09:45, Hans de Goede wrote: 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. So the card arrived today and I've plugged it in tests/trivial/compute looks much better

Re: [Nouveau] NV50 compute support questions

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

Re: [Nouveau] NV50 compute support questions

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 Ha

Re: [Nouveau] NV50 compute support questions

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

Re: [Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?

Please generate a mmt trace, and we can see if anything stands out compared to a blob trace that also does compute. Cheers, -ilia On Tue, Dec 15, 2015 at 9:15 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi all, As part of my compute work I'm trying to get some TGSI compute code to wo

Re: [Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?

hardware chain to work that way. Still would be good to get nbody.c to work though. Regards, Hans Cheers, -ilia On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 15-12-15 20:04, Ilia Mirkin wrote: Also, where's the exit op? Perhaps what's

Re: [Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?

32-bit gmem address, but you need to be using a 64-bit one. I believe the 32-bit ones work on fermi, but afaik not on Kepler. Cheers, -ilia On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 15-12-15 20:04, Ilia Mirkin wrote: Also, where's the exit

[Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?

Hi all, As part of my compute work I'm trying to get some TGSI compute code to work. The code from mesa/src/gallium/tests/trivial.c works. So now I'm trying to get a "native" tgsi kernel to run via clover, I'm using Francisco's nbody.c example for this:

[Nouveau] Translating tests/trivial/compute.c gallium tests to opencl (input / help wanted)

Hi All, I've been working on translating the tests/trivial/compute.c tests to opencl (for the buffer setup and kernel launch, I'm keeping the compute kernels in tgsi as an intermediate step). I've got the test_input_global() test working, see:

Re: [Nouveau] NV50 compute support questions

Hi, On 20-11-15 17:07, Samuel Pitoiset wrote: On 11/20/2015 11:36 AM, Hans de Goede wrote: Hi Samual, et al, Hi Hans, In http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd you write: "This compute support has been t

Re: [Nouveau] NV50 compute support questions

Hi, On 30-11-15 20:03, Ilia Mirkin wrote: On Mon, Nov 30, 2015 at 8:27 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 26-11-15 13:52, Samuel Pitoiset wrote: I do not have a GK106, I've a GK208, and IIRC that one is known to not work, I guess I can give it a try. Compute s

Re: [Nouveau] NV50 compute support questions

Hi, On 26-11-15 13:52, Samuel Pitoiset wrote: I do not have a GK106, I've a GK208, and IIRC that one is known to not work, I guess I can give it a try. Compute support is not supported on GK110+, yeah... If you provide me a MMT trace of, for example, vectorAdd from the CUDA samples I

Re: [Nouveau] NV50 compute support questions

/25/2015 03:43 PM, Hans de Goede wrote: Hi, On 20-11-15 17:07, Samuel Pitoiset wrote: On 11/20/2015 11:36 AM, Hans de Goede wrote: Hi Samual, et al, Hi Hans, In http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd you wri

Re: [Nouveau] [Mesa-dev] llvm TGSI backend (WIP) questions

Hi, On 13-11-15 19:51, Tom Stellard wrote: On Fri, Nov 13, 2015 at 02:46:52PM +0100, Hans de Goede wrote: Hi All, So as discussed I've started working on a TGSI backend for llvm to use as a way to get compute going on nouveau (and other gpu-s). I'm still learning all the ins and outs of llvm

[Nouveau] NV50 compute support questions

Hi Samual, et al, In http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd you write: "This compute support has been tested by Pierre Moreau and myself with some compute kernels." Can you provide testing instructions (and the

Re: [Nouveau] NV50 compute support questions

Hi, On 20-11-15 17:07, Samuel Pitoiset wrote: On 11/20/2015 11:36 AM, Hans de Goede wrote: Hi Samual, et al, Hi Hans, In http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd you write: "This compute support has been t

[Nouveau] Some llvm questions (for tgsi backend)

Hi, After a few distractions I'm back to work on the llvm tgsi backend. I've added clang integration and I can now compile a simple opencl program to something which sort of looks like tgsi. You can find my latest work on this here: http://cgit.freedesktop.org/~jwrdegoede/llvm

Re: [Nouveau] Some llvm questions (for tgsi backend)

Hi Tom, Thanks for taking the time to answer this. On 11-01-16 18:10, Tom Stellard wrote: On Mon, Jan 11, 2016 at 12:07:14PM +0100, Hans de Goede wrote: Hi, After a few distractions I'm back to work on the llvm tgsi backend. I've added clang integration and I can now compile a simple opencl

Re: [Nouveau] Donate NVS 510 and 310 cards

Hi, On 07-06-16 12:13, Ed Avis wrote: I'm in Europe (at least until the 23rd...) so let me know your address. Cool, I'll send you a private mail with my address. My motivation is to get them working reliably under Fedora 23 x86 to drive a Dell UP2414Q 4k monitor, where currently my father's

Re: [Nouveau] Donate NVS 510 and 310 cards

Hi, On 06-06-16 14:27, Ed Avis wrote: Hi, I have some spare Nvidia NVS 310 cards (with two DP1.2 outputs) and at least one NVS 510 (four DP1.2 outputs). Would any Nouveau developer like to accept some as a donation? If you're willing to ship to Europe I would certainly welcome 1 of each

[Nouveau] [PATCH xf86-video-nouveau] Properly cleanup fb for reverse-prime-offload

hed to the dgpu has been used once. Which causes burning through an additional 10W of power and the laptop to run quite hot. This commit adds the missing remove fb call, allowing the dgpu to runtime suspend after an external monitor has been plugged into the laptop. Signed-off-by: Hans de Go

Re: [Nouveau] [PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM

Hi, On 27-05-16 13:10, Peter Wu wrote: On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port can be runtime-suspended which disables power resources

Re: [Nouveau] [xf86-video-nouveau] Properly cleanup fb for reverse-prime-offload

Hi Ilia, Ben, et al. Can I please get a review of this patch, and assuming the review is favorable, can someone please push this ? Regards, Hans p.s. Is it ok if I request push rights to the nouveau repos / group at freedesktop.org ? On 03-06-16 14:46, Hans De Goede wrote

Re: [Nouveau] nouveau contributor dinner Friday evening before FOSDEM?

Hi, On 01/28/2016 11:31 AM, Hans de Goede wrote: Hi All, On 21-01-16 14:09, Hans de Goede wrote: Hi All, $subject says it pretty much all. AFAIk quite a few nouveau contributors are coming to Fosdem, and I think it would be nice to have dinner together Friday evening before FOSDEM. So any

Re: [Nouveau] nouveau contributor dinner Friday evening before FOSDEM?

Hi, On 28-01-16 11:48, Emil Velikov wrote: Hi Hans, On 28 January 2016 at 12:31, Hans de Goede <hdego...@redhat.com> wrote: Hi All, On 21-01-16 14:09, Hans de Goede wrote: Hi All, $subject says it pretty much all. AFAIk quite a few nouveau contributors are coming to Fosdem, and I

Re: [Nouveau] nouveau contributor dinner Friday evening before FOSDEM?

Hi All, On 21-01-16 14:09, Hans de Goede wrote: Hi All, $subject says it pretty much all. AFAIk quite a few nouveau contributors are coming to Fosdem, and I think it would be nice to have dinner together Friday evening before FOSDEM. So any takers? If you want to join please reply

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 19-02-16 20:43, Ilia Mirkin wrote: On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 18-02-16 17:39, Ilia Mirkin wrote: On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede <hdego...@redhat.com> wrote: But this does not seem to be h

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 22-02-16 14:04, Samuel Pitoiset wrote: On 02/22/2016 01:46 PM, Hans de Goede wrote: Hi, On 22-02-16 13:41, Samuel Pitoiset wrote: Hi there, On 02/22/2016 12:26 PM, Hans de Goede wrote: So back to the problem of getting OpenCL(ish) code to work again with the recent mesa changes

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 22-02-16 15:22, Ilia Mirkin wrote: On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 22-02-16 14:47, Ilia Mirkin wrote: On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: INPUT is for shader inputs which com

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 22-02-16 14:47, Ilia Mirkin wrote: On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin wrote: INPUT is for shader inputs which come from fixed function loaders. This is not what you want. You want CONST. Stick the input params into a constbuf, and you're done. Oh, and

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 22-02-16 15:42, Samuel Pitoiset wrote: Well the pipe_loader stuff is buggy in compute.c, I can't even create a screen object... That's sad. It fails in pipe_loader_probe() & co. It works for me on a kepler1 (GT740), at least before the dropping of the RES support some of the tests from

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 22-02-16 17:13, Ilia Mirkin wrote: On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede <hdego...@redhat.com> wrote: But assuming I'm right, what I'm proposing is that instead of passing the input in

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 22-02-16 16:24, Ilia Mirkin wrote: On Mon, Feb 22, 2016 at 9:50 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 22-02-16 15:22, Ilia Mirkin wrote: On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 22-02-16 14:47, Ilia Mirkin wrot

[Nouveau] nouveau contributor dinner Friday evening before FOSDEM?

Hi All, $subject says it pretty much all. AFAIk quite a few nouveau contributors are coming to Fosdem, and I think it would be nice to have dinner together Friday evening before FOSDEM. So any takers? If you want to join please reply to this mail thread before coming Thursday, I will try to

[Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi Ilia and Samuel, I rebased my mesa git tree today (it was getting a bit stale) and after that src/gallium/tests/trivial/compute.c stopped working as well as any opencl programs with the kernel in TGSI (as clover on nouveau currently only supports having the kernel in TGSI). The problem is

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

Hi, On 18-02-16 17:39, Ilia Mirkin wrote: On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede <hdego...@redhat.com> wrote: But this does not seem to be hooked up yet for nouveau. Samuel has patches. See https://cgit.freedesktop.org/~hakzsam/mesa/log/?h=arb_compute_shader_v3 Cool, I wil

Re: [Nouveau] [Mesa-dev] [PATCH mesa 2/3] tgsi: Add support for global / local / input MEMORY

Hi, On 10-03-16 16:35, Aaron Watry wrote: On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdego...@redhat.com> wrote: Extend the MEMORY file support to differentiate between global, local and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intend

Re: [Nouveau] [PATCH mesa 3/3] nouveau: Add support for clover / OpenCL kernel input parameters

04:23 PM, Ilia Mirkin wrote: On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdego...@redhat.com> wrote: Add support for clover / OpenCL kernel input parameters. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 +

[Nouveau] [PATCH mesa 2/3] tgsi: Add support for global / local / input MEMORY

BO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid, "MEMORY[x], INPUT" allows drivers to use an access mechanism for parameter reads which matches with the upload method. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/auxilia

[Nouveau] [PATCH mesa 3/3] nouveau: Add support for clover / OpenCL kernel input parameters

Add support for clover / OpenCL kernel input parameters. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/nouveau/c

[Nouveau] [PATCH mesa 1/3] tgsi: Fix decl.Atomic and .Shared not propagating when parsing tgsi text

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/gallium/aux

[Nouveau] [PATCH mesa 0/3] tgsi and nouveau global / local / opencl-input mem support

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans ___ Nouveau mailing list

Re: [Nouveau] [RFC mesa] nouveau: Add support for OpenCL global memory buffers

that solution #1 (which was also my first hunch) is the right one then I will go and implement that. What I really don't want is to somehow differentiate glsl-sourced and opencl-sourced compute programs in the backend. Ok, understood. Regards, Hans On Mar 14, 2016 6:22 AM, "Han

[Nouveau] [PATCH mesa 6/6] nouveau: codegen: Disable more old resource handling code

r_tokens.h as those are no longer used now (which is a good thing). Signed-off-by: Hans de Goede <hdego...@redhat.com> --- .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 42 +++--- src/gallium/include/pipe/p_shader_tokens.h | 9 - 2 files changed, 30 i

[Nouveau] [PATCH mesa 1/6] tgsi_build: Fix return of uninitialized memory in tgsi_*_instruction_memory

ormat to tgsi_instruction_memory") Cc: Nicolai Hähnle <nicolai.haeh...@amd.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c b/src/

[Nouveau] [PATCH mesa 4/6] nouveau: codegen: s/FILE_MEMORY_GLOBAL/FILE_MEMORY_BUFFER/

handling, this will allow the later (re-)addition of FILE_MEMORY_GLOBAL for regular global memory. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir.h| 2 +- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp

  1   2   3   4   >