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

Do you still have some glitches or does it work correctly now? Did you also remove the spurious wait dep bars between v3 and v4? On 06/27/2017 05:16 PM, Aaryaman Vasishta wrote: v4: Updated the wait dependancy bars based on tex component masks. This patch adds proper delays to maxwell exa shad

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

On 06/28/2017 11:05 AM, Aaryaman Vasishta wrote: Hi, On Wed, Jun 28, 2017 at 12:53 PM, Ilia Mirkin > wrote: BTW, you can drop those explicit "depbar" ops. I think they're only needed when you're doing something weird with barriers. Blob doesn't use t

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 t2

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 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, Samuel Pitoiset mailto:samuel

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 mailto:samuel.pitoi...@gmail.com>> wrote: Nice work! See my comments below, and double-check if some of them can be applied to the shaders I didn't review yet.

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 Vasish

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

"optimmize" ? No need to resend just for that though. Reviewed-by: Samuel Pitoiset 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 gprs used in shared program

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

How about piglit? :) Acked-by: Samuel Pitoiset On 03/30/2017 12:05 PM, Alexandre Courbot wrote: GP10B uses the same 3D class as GP100. Signed-off-by: Alexandre Courbot --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers

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 On 10/27/2016 04:02 PM, Ilia Mirkin wrote: rendercheck -f a8r8g8b8 passes as much as on

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 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 updated format, which is what I t

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 --- src/nvc0_accel.c |

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

Reviewed-by: Samuel Pitoiset On 10/27/2016 04:03 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin --- src/nv_driver.c | 2 ++ src/nvc0_accel.c | 10 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/src/nv_driver.c b/src/nv_driver.c index fff83f8..61940a8 100644

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 On 10/27/2016 04:02 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin --- src/nouveau_copy.c | 2 ++ src/nvc0_accel.c | 10 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git

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 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 GP10x also use this TIC format

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 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 100644 --- a/src/nvc0_exa.c +++ b

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

This requires at least a quick test. :-) Acked-by: Samuel Pitoiset On 10/16/2016 09:14 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin --- Untested. I don't have the hardware. src/nv_driver.c | 2 ++ src/nvc0_accel.c | 10 +- 2 files changed, 11 insertions(+), 1 del

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 | 56 ++

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

Reviewed-by: Samuel Pitoiset 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 --- src/nouveau_local.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/nouveau_local.h

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

Acked-by: Samuel Pitoiset On 10/16/2016 09:14 PM, Ilia Mirkin wrote: These are copied directly from the mesa repository. Signed-off-by: Ilia Mirkin --- src/hwdefs/gm107_texture.xml.h | 365 + src/hwdefs/nvc0_3d.xml.h | 867 + 2

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

Reviewed-by: Samuel Pitoiset On 10/16/2016 09:14 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin --- src/nvc0_accel.c | 2 +- src/nvc0_accel.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c index 52a17db..0682806 100644 --- a/src

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, i

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

s too on Friday. 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

Re: [Nouveau] NVidia Hardware Donation possible

ready 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

Re: [Nouveau] NVidia Hardware Donation possible

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: On

Re: [Nouveau] NVidia Hardware Donation possible

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 wrote: On 10/0

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 r

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 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-off-by: Hans de Goede --- src/gallium/

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 : un

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, but not

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

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

Series is: Reviewed-by: Samuel Pitoiset 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 all of it is dead already, if we ever

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 3/6] nouveau: codegen: gk110: Make emitSTORE offset handling identical to emitLOAD

Reviewed-by: Samuel Pitoiset On 03/16/2016 10:23 AM, Hans de Goede wrote: Make the store offset handling in CodeEmitterGK110::emitSTORE identical to the one in CodeEmitterGK110::emitLOAD handling. This is just a cleanup, it does not cause any functional changes. Signed-off-by: Hans de Goede

Re: [Nouveau] [PATCH mesa 2/6] nouveau: codegen: Slightly refactor Source::scanInstruction() dst handling

Reviewed-by: Samuel Pitoiset On 03/16/2016 10:23 AM, Hans de Goede wrote: Use the dst temp variable which was used in the TGSI_FILE_OUTPUT case everywhere. This makes the code somewhat easier to reads and helps avoiding going over 80 chars with upcoming changes. This also brings the dst

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

Reviewed-by: Samuel Pitoiset 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 Reviewed-by: Ilia Mirkin --- Changes in v2: -s/local/private/ -Add: Reviewed-by: Ilia Mirkin --- .../drivers/nouveau/codegen

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

Reviewed-by: Samuel Pitoiset 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 shared memory, as well as "

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

Reviewed-by: Samuel Pitoiset 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 Reviewed-by: Ilia Mirkin --- Changes in v2: -Add Reviewed-by: Ilia

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 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 wrote: After

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

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 propo

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

Thanks Hans! Reviewed-by: Samuel Pitoiset 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 zero-ing the entire pipe_grid_info

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

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 wrote: After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass

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

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

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. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar pr

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 wrote: Add support for clover / OpenCL kernel input parameters. Signed-off-by: Hans de Goede

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

after 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&id=640d68009bcf93c1814cee0b1a12939cb85e5895 Reviewed-by: Samuel Pitoiset

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 wrote: 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

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 | 18 +++--- 1 file changed, 15 i

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

Reviewed-by: Samuel Pitoiset 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 --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++ 1 file

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

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 wrote: But this does not seem to be hooked up

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, 1 insertion(+), 1 deletion(-) diff --git a/dr

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] [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 --- drm/nouveau

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

On 01/13/2016 01:49 PM, Karol Herbst wrote: Samuel Pitoiset 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 patches and it is easier for

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 ha

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 Thanks for your work! On 12/17/2015 12:20 AM, Ben Skeggs wrote: From: Ben Skeggs This commit

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 w

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

This series is: Reviewed-by: Samuel Pitoiset Tested-by: Samuel Pitoiset On 12/17/2015 12:21 AM, Ben Skeggs wrote: From: Ben Skeggs v2. forgot bump for non-gallium driver Signed-off-by: Ben Skeggs --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a

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

On 12/08/2015 04:30 PM, Emil Velikov wrote: On 8 December 2015 at 14:56, Samuel Pitoiset wrote: 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

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 test

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 support

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 of

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

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:

Re: [Nouveau] NV50 compute support questions

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, Hans de Goede wrote: Hi Samual, et al, Hi Hans, In http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd

Re: [Nouveau] NV50 compute support questions

On 11/20/2015 05:29 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

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 ke

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 rebase

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 Thanks! On 10/10/2015 11:09 AM, Ilia Mirkin wrote: We still have to push everythin

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 wrote: On 10/10/2015 09:58 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 3:55 PM, Samuel Pitoiset wrote: On 10/10/2015 09:42 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 3:41 PM, Samuel

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 wrote: On 10/10/2015 09:42 PM, Ilia Mirkin wrote: On Sat, Oct 10, 2015 at 3:41 PM, Samuel Pitoiset wrote: This patch looks fine except that it should be a bit more normalized. I mean, sometimes

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 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 calls, sometimes you add it sometimes

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, Il

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 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 be able to observe that the fence

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

Reviewed-by: Samuel Pitoiset 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 a bit of extra room for the

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 --- 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/subdev/ibus/gf100.c | 17

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 --- drm/nouveau/nvkm/subdev/clk/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm

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

Only the core clock is currently supported. Signed-off-by: Samuel Pitoiset --- 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 index a52b7e7..807305a 100644 --- a

[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 --- drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau

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

-off-by: Samuel Pitoiset --- 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 ++-- drm/nouveau/nvkm/subdev/ibus

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

-off-by: Samuel Pitoiset --- 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/gf117.c | 51

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

These variables have been left since the recent big merge. Signed-off-by: Samuel Pitoiset --- 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(-) diff --git a/drm

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

o often. Good, I'd be happy to have a look at this second approach. On Mon, Aug 24, 2015 at 4:07 PM, Samuel Pitoiset wrote: Reviewed-by: Samuel Pitoiset 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 hard

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

Reviewed-by: Samuel Pitoiset 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 vertexid-drawarrays Signed

[Nouveau] [PATCH 3/4] pm/gf100: remove multiple definitions of GPC_DOM signal 0x0e

Signed-off-by: Samuel Pitoiset --- drm/nouveau/nvkm/engine/pm/gf100.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drm/nouveau/nvkm/engine/pm/gf100.c b/drm/nouveau/nvkm/engine/pm/gf100.c index 37b1636..ab46389 100644 --- a/drm/nouveau/nvkm/engine/pm/gf100.c +++ b

[Nouveau] [PATCH 4/4] pm/gf100: only use PBFB_BROADCAST.PM_UNK100 for PBFB signals

High level hardware events related to PBFB will monitor all partitions. While we are at it, fix bitfield for this mux. Signed-off-by: Samuel Pitoiset --- drm/nouveau/nvkm/engine/pm/gf100.c | 21 ++--- drm/nouveau/nvkm/engine/pm/gf100.h | 2 +- drm/nouveau/nvkm/engine/pm/gf108.c

[Nouveau] [PATCH 2/4] pm/gf100: remove undefined TEX.PM_UNKC8 mux

This mux only exists on GF108+ (except for GF110 one), but since it is not used by the userspace we can drop it for now. Signed-off-by: Samuel Pitoiset --- drm/nouveau/nvkm/engine/pm/gf100.c | 4 1 file changed, 4 deletions(-) diff --git a/drm/nouveau/nvkm/engine/pm/gf100.c b/drm/nouveau

[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 --- drm/nouveau/nvkm/engine/pm/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/engine/pm/base.c

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

Signed-off-by: Samuel Pitoiset --- 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/nv50.c +++ b/drm/nouveau

[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 --- drm/nouveau/nvkm/engine/pm/g84.c

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 vs-tes-tessinner-tes

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

Reviewed-by: Samuel Pitoiset 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

  1   2   >