Re: [Mesa-dev] radeonsi: NIR - Polaris triangle sprinkling running UH SOLVED - finally
Am 16.02.2019 03:56, schrieb Timothy Arceri: On 13/2/19 8:28 am, Dieter Nützel wrote: Hello Marek, Timo, Nicolai, Timo SOLVED this long-standing NIR corruption on Polaris with his 'nir: rewrite varying component packing' commit. It was triggered with commit 86b52d42368ac496fe24bc6674e754c323381635 Author: Marek Olšák Date: Fri Jul 13 00:23:36 2018 -0400 radeonsi: reduce LDS stalls by 40% for tessellation 40% is the decrease in the LGKM counter (which includes SMEM too) for the GFX9 LSHS stage. This will make the LDS size slightly larger, but I wasn't able to increase the patch stride without corruption, so I'm increasing the vertex stride. and now finally SOLVED with commit 26aa460940f6222565ad5eb40a21c2377c59c3a6 Author: Timothy Arceri Date: Mon Dec 10 10:23:51 2018 +1100 nir: rewrite varying component packing There are a number of reasons for the rewrite. 1. Adding support for packing tess patch varyings in a sane way. 2. Making use of qsort allowing the code to be much easier to follow. 3. Fixes a bug where different interp types caused component packing to be skipped for all varyings in some scenarios. 4. Allows us to add a crude live range analysis for deciding which components should be packed together. This support can optionally be added in a future patch. Reviewed-by: Jason Ekstrand Maybe it should backported (Cc: lists.freedesktop.org>) ) for 19.0? I'd rather it didn't since NIR isn't default for radeonsi and this is use for other drivers like RADV. I'd rather have more testing in the dev branch. Of course, your're right. - Running NIR to long...;-) Dieter BTW 'New' stuttering (shader compiler) with Rocket League went in. Our son is unhappy. Have to dig (bisect). This change really shouldn't fix anything, it could just be that the change avoids the bug. I'm really not sure. One thing this change did fix was a bug with doubles, but I wasn't aware of anything actually using doubles so I doubt this is it. I hope my bisect help to bring some more understanding for this Polaris NIR bug. Now, hunting for the (last) 19.0+ EQAA regression (DiRT Rally, black squares like radv/DXVK corruption, NOT NIR related) and 'meson' OpenCL (Clover) build error. Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] radeonsi: NIR - Polaris triangle sprinkling running UH SOLVED - finally
On 13/2/19 8:28 am, Dieter Nützel wrote: Hello Marek, Timo, Nicolai, Timo SOLVED this long-standing NIR corruption on Polaris with his 'nir: rewrite varying component packing' commit. It was triggered with commit 86b52d42368ac496fe24bc6674e754c323381635 Author: Marek Olšák Date: Fri Jul 13 00:23:36 2018 -0400 radeonsi: reduce LDS stalls by 40% for tessellation 40% is the decrease in the LGKM counter (which includes SMEM too) for the GFX9 LSHS stage. This will make the LDS size slightly larger, but I wasn't able to increase the patch stride without corruption, so I'm increasing the vertex stride. and now finally SOLVED with commit 26aa460940f6222565ad5eb40a21c2377c59c3a6 Author: Timothy Arceri Date: Mon Dec 10 10:23:51 2018 +1100 nir: rewrite varying component packing There are a number of reasons for the rewrite. 1. Adding support for packing tess patch varyings in a sane way. 2. Making use of qsort allowing the code to be much easier to follow. 3. Fixes a bug where different interp types caused component packing to be skipped for all varyings in some scenarios. 4. Allows us to add a crude live range analysis for deciding which components should be packed together. This support can optionally be added in a future patch. Reviewed-by: Jason Ekstrand Maybe it should backported (Cc: ) ) for 19.0? I'd rather it didn't since NIR isn't default for radeonsi and this is use for other drivers like RADV. I'd rather have more testing in the dev branch. This change really shouldn't fix anything, it could just be that the change avoids the bug. I'm really not sure. One thing this change did fix was a bug with doubles, but I wasn't aware of anything actually using doubles so I doubt this is it. I hope my bisect help to bring some more understanding for this Polaris NIR bug. Now, hunting for the (last) 19.0+ EQAA regression (DiRT Rally, black squares like radv/DXVK corruption, NOT NIR related) and 'meson' OpenCL (Clover) build error. Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] radeonsi: NIR - Polaris triangle sprinkling running UH SOLVED - finally
Hello Marek, Timo, Nicolai, Timo SOLVED this long-standing NIR corruption on Polaris with his 'nir: rewrite varying component packing' commit. It was triggered with commit 86b52d42368ac496fe24bc6674e754c323381635 Author: Marek Olšák Date: Fri Jul 13 00:23:36 2018 -0400 radeonsi: reduce LDS stalls by 40% for tessellation 40% is the decrease in the LGKM counter (which includes SMEM too) for the GFX9 LSHS stage. This will make the LDS size slightly larger, but I wasn't able to increase the patch stride without corruption, so I'm increasing the vertex stride. and now finally SOLVED with commit 26aa460940f6222565ad5eb40a21c2377c59c3a6 Author: Timothy Arceri Date: Mon Dec 10 10:23:51 2018 +1100 nir: rewrite varying component packing There are a number of reasons for the rewrite. 1. Adding support for packing tess patch varyings in a sane way. 2. Making use of qsort allowing the code to be much easier to follow. 3. Fixes a bug where different interp types caused component packing to be skipped for all varyings in some scenarios. 4. Allows us to add a crude live range analysis for deciding which components should be packed together. This support can optionally be added in a future patch. Reviewed-by: Jason Ekstrand Maybe it should backported (Cc: ) ) for 19.0? I hope my bisect help to bring some more understanding for this Polaris NIR bug. Now, hunting for the (last) 19.0+ EQAA regression (DiRT Rally, black squares like radv/DXVK corruption, NOT NIR related) and 'meson' OpenCL (Clover) build error. Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
