Re: [Nouveau] [PATCH v3] nv110/exa: update sched codes

On 06/10/2017 09:14 AM, Aaryaman Vasishta wrote: See the 'wt' on the first fmul in exacanv110.fp, exacmnv110.fp and exasanv110.fp. Any ideas on what could be causing the first fmul to require $r0 and/or $r1? 'tex nodep $r4 $r2 0x0 0x1 t2d 0xf' is actually: 'tex nodep $r4:$r7 $r2 0x0 0x1

Re: [Nouveau] [PATCH v2] nv110/exa: update sched codes

On 06/08/2017 05:19 PM, Aaryaman Vasishta wrote: On Thu, Jun 8, 2017 at 5:01 AM, Samuel Pitoiset <samuel.pitoi...@gmail.com <mailto:samuel.pitoi...@gmail.com>> wrote: On 06/07/2017 06:58 PM, Aaryaman Vasishta wrote: On Tue, Jun 6, 2017 at 7:15 AM, Sam

Re: [Nouveau] [PATCH v2] nv110/exa: update sched codes

On 06/07/2017 06:58 PM, Aaryaman Vasishta wrote: On Tue, Jun 6, 2017 at 7:15 AM, Samuel Pitoiset <samuel.pitoi...@gmail.com <mailto:samuel.pitoi...@gmail.com>> wrote: Nice work! See my comments below, and double-check if some of them can be applied to the shad

Re: [Nouveau] [PATCH v2] nv110/exa: update sched codes

Nice work! See my comments below, and double-check if some of them can be applied to the shaders I didn't review yet. I recommend you to test your work because if one sched code is wrong, you are likely going to kill your card and reboot your box. :-) On 06/03/2017 04:16 PM, Aaryaman

Re: [Nouveau] [PATCH] nv50/ir: optimmize shl(a, 0) to a

"optimmize" ? No need to resend just for that though. Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 04/29/2017 06:46 PM, Karol Herbst wrote: helps two alien isolation shaders shader-db: total instructions in shared programs : 4251497 -> 4251494 (-0.00%) total

Re: [Nouveau] [PATCH] nvc0: support for GP10B

How about piglit? :) Acked-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 03/30/2017 12:05 PM, Alexandre Courbot wrote: GP10B uses the same 3D class as GP100. Signed-off-by: Alexandre Courbot <acour...@nvidia.com> --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + 1

Re: [Nouveau] [PATCH v2 1/7] exa: add GM10x acceleration support

Two minor nitpicks below. I didn't read all shaders carefully because it's a pain, but I didn't see any obvious things. :-) Thanks for that great work Ilia! Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/27/2016 04:02 PM, Ilia Mirkin wrote: rendercheck -f a8r8g8b8

Re: [Nouveau] [PATCH v2 5/7] nvc0: refactor TIC uploads to allow different specifics per generation

On 10/27/2016 07:28 PM, Ilia Mirkin wrote: On Thu, Oct 27, 2016 at 1:19 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: Are you sure this refactoring doesn't break anything? Few comments inline. On 10/27/2016 04:02 PM, Ilia Mirkin wrote: This flips GM10x to using the u

Re: [Nouveau] [PATCH v2 5/7] nvc0: refactor TIC uploads to allow different specifics per generation

Are you sure this refactoring doesn't break anything? Few comments inline. On 10/27/2016 04:02 PM, Ilia Mirkin wrote: This flips GM10x to using the updated format, which is what I tested with. However GM20x and GP10x also use this TIC format. Signed-off-by: Ilia Mirkin

Re: [Nouveau] [PATCH v2 7/7] recognize and accelerate GM20x

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/27/2016 04:03 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nv_driver.c | 2 ++ src/nvc0_accel.c | 10 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/src/n

Re: [Nouveau] [PATCH v2 6/7] copy: add maxwell/pascal copy engine classes

0xc0b5 is not in rnndb, I guess it should be GP100_COPY, right? Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/27/2016 04:02 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nouveau_copy.c | 2 ++ src/nvc0_accel.c | 10 +++

Re: [Nouveau] [PATCH 4/5] nvc0: refactor TIC uploads to allow different specifies per generation

On 10/17/2016 02:24 PM, Ilia Mirkin wrote: On Mon, Oct 17, 2016 at 5:46 AM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: Few comments below. On 10/16/2016 09:14 PM, Ilia Mirkin wrote: This flips GM10x to using the updated format, which is what I tested with. However GM20x and

Re: [Nouveau] [PATCH] exa: add GM10x acceleration support

On 10/17/2016 02:27 PM, Ilia Mirkin wrote: On Mon, Oct 17, 2016 at 5:28 AM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: Looks reasonable, some minor comments below. On 10/16/2016 02:06 AM, Ilia Mirkin wrote: diff --git a/src/nvc0_exa.c b/src/nvc0_exa.c index 6add60b..a53dfe6

Re: [Nouveau] [PATCH 5/5] recognize and accelerate GM20x

This requires at least a quick test. :-) Acked-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/16/2016 09:14 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Untested. I don't have the hardware. src/nv_driver.c | 2 ++ src/nvc0_accel.c | 10 +

Re: [Nouveau] [PATCH 4/5] nvc0: refactor TIC uploads to allow different specifies per generation

Few comments below. On 10/16/2016 09:14 PM, Ilia Mirkin wrote: This flips GM10x to using the updated format, which is what I tested with. However GM20x and GP10x also use this TIC format. Signed-off-by: Ilia Mirkin --- src/nvc0_accel.c | 11 ++ src/nvc0_accel.h

Re: [Nouveau] [PATCH 3/5] nvc0: rename BEGIN_IMC0 to IMMED_NVC0

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/16/2016 09:14 PM, Ilia Mirkin wrote: For consistency with mesa. It wasn't used anywhere previously. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nouveau_local.h | 2 +- 1 file changed, 1 insertion(+)

Re: [Nouveau] [PATCH 1/5] hwdefs: update nvc0_3d, add gm107_texture for new TIC format

Acked-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/16/2016 09:14 PM, Ilia Mirkin wrote: These are copied directly from the mesa repository. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/hwdefs/gm107_texture.xml.h | 365 + src/hwdefs/n

Re: [Nouveau] [PATCH 2/5] nvc0: make use of the new hwdefs for TEX_CB_INDEX

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/16/2016 09:14 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nvc0_accel.c | 2 +- src/nvc0_accel.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/nvc0_a

Re: [Nouveau] [PATCH] exa: add GM10x acceleration support

Looks reasonable, some minor comments below. On 10/16/2016 02:06 AM, Ilia Mirkin wrote: rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to work. Very lightly tested. Instead of sticking coordinates into pushbufs, the vertex shader is modified to read them from a constbuf,

Re: [Nouveau] NVidia Hardware Donation possible

On 10/12/2016 05:54 PM, Gediminas Jakutis wrote: On 2016.10.11 17:46, Samuel Pitoiset wrote: On 10/11/2016 02:18 PM, Martin Vorbach wrote: Samuel, the HP GT630 is unfortunately the GK107. Given we find the other GT630 model I will check it and come back to you. Are you interested in any

Re: [Nouveau] NVidia Hardware Donation possible

. If this attempt to get a GK208 fails, I will have to give up. The guys here are about to kill me ;-) Regards, Martin On 2016-10-11 16:46, Samuel Pitoiset wrote: On 10/11/2016 02:18 PM, Martin Vorbach wrote: Samuel, the HP GT630 is unfortunately the GK107. Given we find the other GT630

Re: [Nouveau] NVidia Hardware Donation possible

have a bunch of Tesla, Fermi and one Maxwell. Regards, Martin On 2016-10-10 13:45, Samuel Pitoiset wrote: On 10/10/2016 01:44 PM, Martin Vorbach wrote: Hi, I talked to our IT guy over lunch. He thinks there is an old GT630 with 384 shaders somewhere. The 384 shader GPU is the GK208

Re: [Nouveau] NVidia Hardware Donation possible

this one too. Let me know if you are looking for this one. Regards, Martin On 2016-10-10 11:09, Martin Vorbach wrote: Hi, the GT630 is this one: http://www8.hp.com/emea_africa/en/products/oas/product-detail.html?oid=5275291 Regards, Martin On 2016-10-07 18:16, Samuel Pitoiset wrote

Re: [Nouveau] NVidia Hardware Donation possible

Fermi one. But would it be possible to plug it into a computer and check for sure? Lspci delivers the information Yes, that would be nice to check the real chipset. :-) If it's a Kepler I'm definitely interested (because I don't have one). Thanks! On 2016-10-07 18:16, Samuel Pitoiset

Re: [Nouveau] NVidia Hardware Donation possible

On 10/07/2016 12:24 PM, Martin Vorbach wrote: Hi, Hi, I'm interested. :) Is the GeForce GT 630 a GK208? Thanks! I saw the donation requests and could offer the following cards: * Geforce N460GTX * Geforce GT 630 * Quadro K4200 Feel free to contact me in case of interest. Best

Re: [Nouveau] [PATCH] nouveau: Add missing PIPE_SHADER_CAP_INTEGERS to get_shader_param()

The prefix should be "nv30:" instead of "nouveau:" I guess. Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 04/11/2016 02:13 PM, Hans de Goede wrote: Add missing PIPE_SHADER_CAP_INTEGERS for frag shaders to nv30_screen_get_shader_param(). Signed-of

Re: [Nouveau] "unknown fragment shader param 17" error on NV46 when running glxgears

On 04/11/2016 12:10 PM, Hans de Goede wrote: Hi, Hi, While trying to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1325667 I also gave glxgears a quick test with mesa master, this resulted in the following errors being printed to the terminal from which glxgears was started :

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

On 03/16/2016 11:49 AM, Hans de Goede wrote: Hi, On 16-03-16 11:45, Samuel Pitoiset wrote: On 03/16/2016 10:23 AM, Hans de Goede wrote: Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled / commented out some of the old resource handling code, b

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

On 03/17/2016 05:07 PM, Hans de Goede wrote: Hi, On 14-03-16 21:50, Samuel Pitoiset wrote: Btw, do you need someone with commit access to push your previous series (the tgsi thing)? I can do this for you. Thanks for the offer. IIRC Ilia wanted some minor fixes there, so I'll do a v2

Re: [Nouveau] [PATCH mesa v2 1/3] nouveau: codegen: Disable more old resource handling code

Series is: Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 03/17/2016 10:13 AM, Hans de Goede wrote: Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled / commented out some of the old resource handling code, but not all of it. Effectively a

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

On 03/16/2016 10:23 AM, Hans de Goede wrote: Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled / commented out some of the old resource handling code, but not all of it. Effectively all of it is dead already, if we ever enter the old code paths in handeLOAD / handleSTORE

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

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 03/16/2016 09:55 AM, Hans de Goede wrote: Add support for clover / OpenCL kernel input parameters. Signed-off-by: Hans de Goede <hdego...@redhat.com> Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu> --- Changes in v2

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

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> Btw, usually when someone has reviewed the v1 we add (v1) after the Rb tag, like: Reviewed-by: XXX (v1) On 03/16/2016 09:55 AM, Hans de Goede wrote: Extend the MEMORY file support to differentiate between global, private and

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

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 03/16/2016 09:55 AM, Hans de Goede wrote: 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> Revie

Re: [Nouveau] [PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized

On 03/14/2016 09:49 PM, Francisco Jerez wrote: Samuel Pitoiset <samuel.pitoi...@gmail.com> writes: On 03/14/2016 02:29 PM, Samuel Pitoiset wrote: On 03/14/2016 02:26 PM, Hans de Goede wrote: Hi, On 14-03-16 14:01, Samuel Pitoiset wrote: On 03/14/2016 01:50 PM, Hans de Goede

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

On 03/14/2016 08:50 PM, Hans de Goede wrote: Hi, On 14-03-16 16:41, Samuel Pitoiset wrote: On 03/14/2016 04:28 PM, Hans de Goede wrote: Hi, On 14-03-16 16:05, Ilia Mirkin wrote: There's a less hacky and more hacky way forward. The more hacky solution is to set file index to -1

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

On 03/14/2016 04:28 PM, Hans de Goede wrote: Hi, On 14-03-16 16:05, Ilia Mirkin wrote: There's a less hacky and more hacky way forward. The more hacky solution is to set file index to -1 or something and then not do the lowering when you see that. The less hacky solution is the one you

Re: [Nouveau] [PATCH mesa v2] clover: Fix pipe_grid_info.indirect not being initialized

Thanks Hans! Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 03/14/2016 03:01 PM, Hans de Goede wrote: After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by ze

Re: [Nouveau] [PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized

On 03/14/2016 02:26 PM, Hans de Goede wrote: Hi, On 14-03-16 14:01, Samuel Pitoiset wrote: On 03/14/2016 01:50 PM, Hans de Goede wrote: After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid

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

On 03/10/2016 05:03 PM, Pierre Moreau wrote: On 04:27 PM - Mar 10 2016, Samuel Pitoiset wrote: On 03/10/2016 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. Sign

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

my changes but that doesn't change anything for you. I already have a patch for the nv50 bits btw, maybe it's the right time to send it? https://cgit.freedesktop.org/~hakzsam/mesa/commit/?h=compute=640d68009bcf93c1814cee0b1a12939cb85e5895 Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.

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

On 03/10/2016 04:43 PM, Ilia Mirkin wrote: On Thu, Mar 10, 2016 at 10:27 AM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: On 03/10/2016 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 / O

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

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

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

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 03/10/2016 04:14 PM, Hans de Goede wrote: 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> ---

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

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. On 02/22/2016 02:08 PM, Hans de Goede wrote: Hi, On 22-02-16 14:04, Samuel Pitoiset wrote: On 02/22/2016 01:46 PM, Hans de Goede wrote: Hi, On 22-0

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

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. For starters I would like to get: src

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

Hi there, On 02/22/2016 12:26 PM, Hans de Goede wrote: Hi, On 19-02-16 20:43, Ilia Mirkin wrote: On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede wrote: Hi, On 18-02-16 17:39, Ilia Mirkin wrote: On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede

Re: [Nouveau] [PATCH] pci: fix typo in nvkm_pcie_set_link()

On 02/03/2016 10:33 AM, Alexandre Courbot wrote: Fix a test that would either do nothing on PCI systems, or crash badly on Tegra. Signed-off-by: Alexandre Courbot Cc: Karol Herbst --- drm/nouveau/nvkm/subdev/pci/pcie.c | 2 +- 1 file changed,

Re: [Nouveau] [PATCH 0/2] allow partly reclocking on chipset

Hi! Did you check on different Fermi chipsets or only with one variant? Are you sure that engine reclocking works as expected on Fermi? Because enabling it without a strong inspection sounds like a prediction and it might not work. On 01/13/2016 01:25 PM, Karol Herbst wrote: some chipset

Re: [Nouveau] [PATCH] debugfs: don't emit parameter names

On 01/13/2016 02:12 PM, Karol Herbst wrote: fixes a compile error Yeah, and this is probably not the only error you will hit... This is happens when CONFIG_DEBUG_FS is set. You need to include "nouveau_drm.h" and to fix nouveau_debugfs.c too. Signed-off-by: Karol Herbst

Re: [Nouveau] [PATCH 0/2] allow partly reclocking on chipset

On 01/13/2016 01:49 PM, Karol Herbst wrote: Samuel Pitoiset <samuel.pitoi...@gmail.com> hat am 13. Januar 2016 um 13:43 geschrieben: Hi! Did you check on different Fermi chipsets or only with one variant? currently I only checked that on my nvc1, but I thought I could just send the p

Re: [Nouveau] [PATCH] debugfs: don't emit parameter names

On 01/13/2016 02:33 PM, Samuel Pitoiset wrote: On 01/13/2016 02:12 PM, Karol Herbst wrote: fixes a compile error Yeah, and this is probably not the only error you will hit... This is happens when CONFIG_DEBUG_FS is set. You need to include "nouveau_drm.h" and to fix nouveau_deb

Re: [Nouveau] [mesa v3 8/9] nvc0: remove use of deprecated sw class identifier

On 12/18/2015 11:19 AM, Emil Velikov wrote: The commit summary "remove use of deprecated..." is no longer applicable. Feel free to tweak (use nvif provided class name/define ?) before pushing. Well, the commit summary is fine by me because the old sw class identifier is actually deprecated

Re: [Nouveau] [libdrm v3 01/14] nouveau: import and install a selection of nvif headers from the kernel

Hi Ben, I don't feel comfortable enough with the libdrm nouveau code to give you my Rb for this series, but as this seems work as expected, this series is: Tested-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> Thanks for your work! On 12/17/2015 12:20 AM, Ben Skeggs wrote: Fro

Re: [Nouveau] [mesa v3 1/9] nouveau: bump required libdrm version to 2.4.66

This series is: Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> Tested-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 12/17/2015 12:21 AM, Ben Skeggs wrote: From: Ben Skeggs <bske...@redhat.com> v2. forgot bump for non-gallium driver Signed-off-by: Ben Skeggs &

Re: [Nouveau] [mesa v2 8/9] nvc0: remove allocation of unused sw class

NACK. This patches breaks MP performance counters on Fermi/Kepler because they actually use software methods to configure multiplexers. Global perf counters will also use software methods to init, sample and read hardware counters, so this SW object is definitely needed. Instead of removing

Re: [Nouveau] NV50 compute support questions

On 12/07/2015 04:10 PM, Hans de Goede wrote: Hi 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

Re: [Nouveau] NV50 compute support questions

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

Re: [Nouveau] NV50 compute support questions

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/~

Re: [Nouveau] NV50 compute support questions

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. > >

Re: [Nouveau] NV50 compute support questions

On 11/30/2015 04:13 PM, Samuel Pitoiset wrote: On 11/30/2015 02:27 PM, Hans de Goede 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 support is not supported

Re: [Nouveau] NV50 compute support questions

On 11/30/2015 02:27 PM, Hans de Goede 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 support is not supported on GK110+, yeah... If you provide me a MMT trace

Re: [Nouveau] NV50 compute support questions

Well, if you remove that assert locally, all compute tests in src/gallium/tests/trivial/compute.c pass on GK106, except the atomic ones. I'm working on the fermi case btw. On 11/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

Re: [Nouveau] NV50 compute support questions

On 11/26/2015 01:21 PM, Hans de Goede wrote: Hi, On 26-11-15 09:42, Samuel Pitoiset wrote: Well, if you remove that assert locally, all compute tests in src/gallium/tests/trivial/compute.c pass on GK106, except the atomic ones. Do you mean the: Assertion `pres->target != PIPE_BUF

Re: [Nouveau] NV50 compute support questions

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 tested by Pierre Moreau and myself with some compute

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

On 11/13/2015 02:46 PM, Hans de Goede wrote: Hi All, Hey Hans, 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

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

I did a full piglit run on Fermi. There are no regressions and you fixed texelFetch tests and other ones which failed with that assert. I'm lazy to do it on Tesla, so: Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> Thanks! On 10/10/2015 11:09 AM, Ilia Mirkin wrote: We stil

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

On 10/10/2015 09:42 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 3:41 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: This patch looks fine except that it should be a bit more normalized. I mean, sometimes you break when PUSH_SPACE fails, sometimes not. Same for PUSH_SPACE

Re: [Nouveau] [Mesa-dev] [PATCH] nouveau: avoid emitting new fences unnecessarily

Does this fix those texelFetch piglit tests ? Or is it the second patch ? Anyway, this patch is : Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/10/2015 08:12 AM, Ilia Mirkin wrote: Right now we emit on every kick, but this is only necessary if something will ever b

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

This patch looks fine except that it should be a bit more normalized. I mean, sometimes you break when PUSH_SPACE fails, sometimes not. Same for PUSH_SPACE calls, sometimes you add it sometimes not. Did you run a full piglit test this time ? :) See my comment below. On 10/10/2015 11:09 AM,

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

On 10/10/2015 09:58 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 3:55 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: On 10/10/2015 09:42 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 3:41 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: This patch looks

Re: [Nouveau] [PATCH] nv50, nvc0: don't base decisions on available pushbuf space

On 10/10/2015 10:17 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 4:21 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: On 10/10/2015 09:58 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 3:55 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: On 10/10/2015 09:42 PM,

Re: [Nouveau] [PATCH] nouveau: make sure there's always room to emit a fence

Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> On 10/05/2015 09:21 PM, Ilia Mirkin wrote: I started seeing a lot of situations on nv30 where fence emission wouldn't fit into the previous buffer (causing assertions). This ensures that whenever checking for space, we always leave

Re: [Nouveau] [PATCH] [resend] nouveau: Disable AGP for SiS 761

This patch has been merged by Ben yesterday. http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=8c713f90a63ffca10d122af09d439f3409c933ed Why do you send a new version ? Is the previous patch wrong? On 09/30/2015 01:48 PM, Ondrej Zary wrote: SiS 761 chipset does not support AGP cards but

[Nouveau] [PATCH v3] ibus/gf100: increase wait timeout to avoid read faults

-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> --- V3: changed some nvkm_mask() to nvkm_wr32() for gf100 (as the blob does) drm/nouveau/include/nvkm/subdev/ibus.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 4 +-- drm/nouveau/nvkm/subdev/ibus/Kbuild| 1 + drm/nouveau/nvkm/

[Nouveau] [PATCH 1/2] fb/ramgf100: disable memory reclocking by default

Although memory reclocking seems to be completely broken on my GF119, we can at least allow users to enable reclocking for the core clock. Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> --- drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +- 1 file changed, 1 insertion(+), 1 de

Re: [Nouveau] [PATCH 2/2] clk/gf100: allow users to enable reclocking

On 09/24/2015 12:00 AM, Martin Peres wrote: On 24/09/15 00:20, Samuel Pitoiset wrote: Only the core clock is currently supported. Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> --- drm/nouveau/nvkm/subdev/clk/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Nouveau] [PATCH 2/2] clk/gf100: allow users to enable reclocking

Only the core clock is currently supported. Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> --- drm/nouveau/nvkm/subdev/clk/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/clk/gf100.c b/drm/nouveau/nvkm/subdev/clk/gf100.c

[Nouveau] [PATCH] ibus/gf100: increase wait timeout to avoid read faults

-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> --- drm/nouveau/include/nvkm/subdev/ibus.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 4 +-- drm/nouveau/nvkm/subdev/ibus/Kbuild| 1 + drm/nouveau/nvkm/subdev/ibus/gf100.c | 17 ++-- drm/nouveau/nvkm/subdev/ibus/g

[Nouveau] [PATCH v2] ibus/gf100: increase wait timeout to avoid read faults

-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> --- V2: increase mask for the gf100 case drm/nouveau/include/nvkm/subdev/ibus.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 4 +-- drm/nouveau/nvkm/subdev/ibus/Kbuild| 1 + drm/nouveau/nvkm/subdev/ibus/gf100.c | 17 ++-

[Nouveau] [PATCH] core: remove unused variables detected by Clang

These variables have been left since the recent big merge. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- drm/nouveau/nvkm/engine/device/base.c | 4 drm/nouveau/nvkm/engine/dma/base.c| 5 - drm/nouveau/nvkm/engine/sw/base.c | 5 - 3 files changed, 14 deletions

Re: [Nouveau] [Mesa-dev] [PATCH] nv50: avoid using inline vertex data submit when gl_VertexID is used

be happy to have a look at this second approach. On Mon, Aug 24, 2015 at 4:07 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: Reviewed-by: Samuel Pitoiset samuel.pitoi...@gmail.com This fix is simpler than I was expected. What about the edge flag stuff now? :) On 08/24/2015 05:51 PM, Ilia

Re: [Nouveau] [Mesa-dev] [PATCH] nv50: avoid using inline vertex data submit when gl_VertexID is used

Reviewed-by: Samuel Pitoiset samuel.pitoi...@gmail.com This fix is simpler than I was expected. What about the edge flag stuff now? :) On 08/24/2015 05:51 PM, Ilia Mirkin wrote: The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements

[Nouveau] [PATCH 1/4] pm: allow zeroed signals to enable sources

Hardware signals index 0x00 are defined for some domains and they have to be allowed to enable sources like the others. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- drm/nouveau/nvkm/engine/pm/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drm

[Nouveau] [PATCH 1/2] pm/nv50: fix wrong addr for ZCULL source on G80:GT215

Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- drm/nouveau/nvkm/engine/pm/nv50.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engine/pm/nv50.c b/drm/nouveau/nvkm/engine/pm/nv50.c index a778bc7..14d474b 100644 --- a/drm/nouveau/nvkm/engine/pm

[Nouveau] [PATCH 2/2] pm/nv50: TPC[0x3] must be used for PGRAPH muxs on G80

I thought that using TPC[0x0] like for G84:GT215 was sufficient on G80, but it's actually not the case. According to NVIDIA PerfKit on Windows, we have to configure PGRAPH related muxs on TPC[0x3] for this chipset. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- drm/nouveau/nvkm

Re: [Nouveau] [Mesa-dev] [PATCH] nvc0: bind a fake tess control program when there isn't one available

On 07/26/2015 06:56 AM, Ilia Mirkin wrote: Apparently this is necessary in order for tess factors to work in a tess eval program without a tess control program bound. Probably because it uses the fake program's shader header to work out the number of patch constants. Fixes

Re: [Nouveau] [PATCH] nv50: adjust min/max lod by base level on G80

Reviewed-by: Samuel Pitoiset samuel.pitoi...@gmail.com On 07/20/2015 09:26 AM, Ilia Mirkin wrote: Make the assumption that there's a 1:1 TIC - TSC connection, and increase min/max lod by the relevant texture's base level. Also if there's no mipfilter, we have to enable it while forcing min/max

Re: [Nouveau] [Mesa-dev] [PATCH] nvc0: fix geometry program revalidation of clipping params

/listinfo/mesa-dev -- Best regards, Samuel Pitoiset. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC PATCH 3/8] nv50: allocate and map a notifier buffer object for PM

On 06/26/2015 01:02 AM, Ilia Mirkin wrote: On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: This notifier buffer object will be used to read back global performance counters results written by the kernel. For each domain, we will store the handle

Re: [Nouveau] [RFC PATCH 6/8] nv50: add support for compute/graphics global performance counters

On 06/26/2015 01:09 AM, Ilia Mirkin wrote: What's with the \%'s everywhere? Maybe percent will be better ? On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: This commit adds support for both compute and graphics global performance counters which have been

Re: [Nouveau] [RFC PATCH 4/8] nv50: configure the ring buffer for reading back PM counters

, this sounds good to me. On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: To write data at the right offset, the kernel has to know some parameters of this ring buffer, like the number of domains and the maximum number of queries. Signed-off-by: Samuel Pitoiset

Re: [Nouveau] [Mesa-dev] [RFC PATCH 5/8] nv50: prevent NULL pointer dereference with pipe_query functions

On 06/23/2015 08:57 AM, Michel Dänzer wrote: On 23.06.2015 06:02, Samuel Pitoiset wrote: On 06/22/2015 10:52 PM, Ilia Mirkin wrote: If query_create fails, why would any of these functions get called? Because the HUD doesn't check if query_create() fails and it calls other pipe_query

[Nouveau] [RFC PATCH 6/8] nv50: add support for compute/graphics global performance counters

later. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- src/gallium/drivers/nouveau/nv50/nv50_query.c | 1057 +++- src/gallium/drivers/nouveau/nv50/nv50_screen.h | 35 + 2 files changed, 1087 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers

[Nouveau] [RFC PATCH 3/8] nv50: allocate and map a notifier buffer object for PM

in order to prevent stalls when reading queries. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 29 ++ src/gallium/drivers/nouveau/nv50/nv50_screen.h | 6 ++ 2 files changed, 35 insertions(+) diff --git a/src

[Nouveau] [RFC PATCH 7/8] nv50: expose global performance counters to the HUD

Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- src/gallium/drivers/nouveau/nv50/nv50_query.c | 41 ++ src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.h | 3 ++ 3 files changed, 45 insertions(+) diff --git

[Nouveau] [RFC PATCH 0/8] nv50: expose global performance counters

series which exposes global performance counters for Fermi and Kepler will be submitted once I have got enough reviews for this one. Feel free to make a review. Thanks, Samuel. Samuel Pitoiset (8): nouveau: implement the nvif hardware performance counters interface nv50: allocate a software

[Nouveau] [RFC PATCH 8/8] nv50: enable GL_AMD_performance_monitor

This exposes a group of global performance counters that enables GL_AMD_performance_monitor. All piglit tests are okay. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- src/gallium/drivers/nouveau/nv50/nv50_query.c | 35 ++ src/gallium/drivers/nouveau/nv50

[Nouveau] [RFC PATCH 5/8] nv50: prevent NULL pointer dereference with pipe_query functions

This may happen when nv50_query_create() fails to create a new query. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- src/gallium/drivers/nouveau/nv50/nv50_query.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nv50

[Nouveau] [RFC PATCH 4/8] nv50: configure the ring buffer for reading back PM counters

To write data at the right offset, the kernel has to know some parameters of this ring buffer, like the number of domains and the maximum number of queries. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 7 +++ 1 file changed, 7

  1   2   >