Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
On Wed, 2014-09-03 at 15:00 -0700, Jordan Justen wrote: On 2014-09-03 10:41:02, Kenneth Graunke wrote: On Tuesday, September 02, 2014 06:16:01 PM Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam Hi Sam, Layered clears now use GL_AMD_vertex_shader_layered. If you expose the extension, then gl-3.2-layered-rendering-clear-color starts passing again. Otherwise, the vertex shader code to set gl_LayerID = gl_InstanceID is #ifdef'd out, so only layer 0 would get affected. Exposing the extension fixes the issue for our tests and piglit's bin/gl-3.2-layered-rendering-clear-color* tests :-) I'm not sure if we can expose that extension without GL 3.2, so you might just put the patch to enable it (simply editing intel_extensions.c) near the end of your series. Perhaps Jordan will know if we can just turn it on now. Yes, We should be able to enable GL_AMD_vertex_shader_layered for gen6 now. But, it really only makes sense to enable it at the same time as enabling 3.2 so the glFramebufferTexture function is available. Due to this meta quirk, it sounds like we should enable them both in the same patch. (Or, perhaps the extension in the patch just before 3.2. ??) We are going to add it in the same patch where OpenGL 3.2 is enabled. Thanks! Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
On Tuesday, September 02, 2014 06:16:01 PM Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam Hi Sam, Layered clears now use GL_AMD_vertex_shader_layered. If you expose the extension, then gl-3.2-layered-rendering-clear-color starts passing again. Otherwise, the vertex shader code to set gl_LayerID = gl_InstanceID is #ifdef'd out, so only layer 0 would get affected. I'm not sure if we can expose that extension without GL 3.2, so you might just put the patch to enable it (simply editing intel_extensions.c) near the end of your series. Perhaps Jordan will know if we can just turn it on now. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
On 2014-09-03 10:41:02, Kenneth Graunke wrote: On Tuesday, September 02, 2014 06:16:01 PM Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam Hi Sam, Layered clears now use GL_AMD_vertex_shader_layered. If you expose the extension, then gl-3.2-layered-rendering-clear-color starts passing again. Otherwise, the vertex shader code to set gl_LayerID = gl_InstanceID is #ifdef'd out, so only layer 0 would get affected. I'm not sure if we can expose that extension without GL 3.2, so you might just put the patch to enable it (simply editing intel_extensions.c) near the end of your series. Perhaps Jordan will know if we can just turn it on now. Yes, We should be able to enable GL_AMD_vertex_shader_layered for gen6 now. But, it really only makes sense to enable it at the same time as enabling 3.2 so the glFramebufferTexture function is available. Due to this meta quirk, it sounds like we should enable them both in the same patch. (Or, perhaps the extension in the patch just before 3.2. ??) -Jordan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
On Wed, Sep 3, 2014 at 10:00 PM, Jordan Justen jljus...@gmail.com wrote: On 2014-09-03 10:41:02, Kenneth Graunke wrote: On Tuesday, September 02, 2014 06:16:01 PM Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam Hi Sam, Layered clears now use GL_AMD_vertex_shader_layered. If you expose the extension, then gl-3.2-layered-rendering-clear-color starts passing again. Otherwise, the vertex shader code to set gl_LayerID = gl_InstanceID is #ifdef'd out, so only layer 0 would get affected. I'm not sure if we can expose that extension without GL 3.2, so you might just put the patch to enable it (simply editing intel_extensions.c) near the end of your series. Perhaps Jordan will know if we can just turn it on now. Yes, We should be able to enable GL_AMD_vertex_shader_layered for gen6 now. But, it really only makes sense to enable it at the same time as enabling 3.2 so the glFramebufferTexture function is available. Due to this meta quirk, it sounds like we should enable them both in the same patch. (Or, perhaps the extension in the patch just before 3.2. ??) Is this something we can do for 10.3 or should we a non-GS version of (fast) clear for 10.3? Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
On Wednesday, September 03, 2014 11:00:06 PM Kristian Høgsberg wrote: On Wed, Sep 3, 2014 at 10:00 PM, Jordan Justen jljus...@gmail.com wrote: On 2014-09-03 10:41:02, Kenneth Graunke wrote: On Tuesday, September 02, 2014 06:16:01 PM Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam Hi Sam, Layered clears now use GL_AMD_vertex_shader_layered. If you expose the extension, then gl-3.2-layered-rendering-clear-color starts passing again. Otherwise, the vertex shader code to set gl_LayerID = gl_InstanceID is #ifdef'd out, so only layer 0 would get affected. I'm not sure if we can expose that extension without GL 3.2, so you might just put the patch to enable it (simply editing intel_extensions.c) near the end of your series. Perhaps Jordan will know if we can just turn it on now. Yes, We should be able to enable GL_AMD_vertex_shader_layered for gen6 now. But, it really only makes sense to enable it at the same time as enabling 3.2 so the glFramebufferTexture function is available. Due to this meta quirk, it sounds like we should enable them both in the same patch. (Or, perhaps the extension in the patch just before 3.2. ??) Is this something we can do for 10.3 or should we a non-GS version of (fast) clear for 10.3? Kristian It doesn't matter for 10.3 - this only affects layered rendering, which is not available prior to GL 3.2 because the glFramebufferTexture() function is missing. Sandybridge only supports GL 3.1 on the 10.3 branch. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam [0] http://lists.freedesktop.org/archives/mesa-dev/2014-August/065692.html [1] https://github.com/samuelig/mesa/tree/gs-support-snb-for-submission-02092014 [2] commit 2f28a0dc23165123cf1e8b5942acad37878edd8a Author: Kristian Høgsberg k...@bitplanet.net Date: Mon Jul 7 16:44:58 2014 -0700 i965: Implement fast color clears using meta operations This patch uses the infrastructure put in place by previous patches to implement fast color clears and replicated color clears in terms of meta operations. This works all the way back to gen7 where fast clear was introduced and adds support for fast clear on gen8. It replaces the blorp path completely and improves on a few cases. Layered clears are now done using instanced rendering and multiple render-target clears use a MRT shader with rep16 writes. Signed-off-by: Kristian Høgsberg k...@bitplanet.net Acked-by: Kenneth Graunke kenn...@whitecape.org [3] http://people.igalia.com/siglesias/mesa/all-gs-patches-v2/changes.html signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
Adding Kristian in Cc. Sam On Tue, 2014-09-02 at 18:16 +0200, Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam [0] http://lists.freedesktop.org/archives/mesa-dev/2014-August/065692.html [1] https://github.com/samuelig/mesa/tree/gs-support-snb-for-submission-02092014 [2] commit 2f28a0dc23165123cf1e8b5942acad37878edd8a Author: Kristian Høgsberg k...@bitplanet.net Date: Mon Jul 7 16:44:58 2014 -0700 i965: Implement fast color clears using meta operations This patch uses the infrastructure put in place by previous patches to implement fast color clears and replicated color clears in terms of meta operations. This works all the way back to gen7 where fast clear was introduced and adds support for fast clear on gen8. It replaces the blorp path completely and improves on a few cases. Layered clears are now done using instanced rendering and multiple render-target clears use a MRT shader with rep16 writes. Signed-off-by: Kristian Høgsberg k...@bitplanet.net Acked-by: Kenneth Graunke kenn...@whitecape.org [3] http://people.igalia.com/siglesias/mesa/all-gs-patches-v2/changes.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
Hi Samuel, On 02/09/14 17:22, Samuel Iglesias Gonsálvez wrote: Adding Kristian in Cc. Sam On Tue, 2014-09-02 at 18:16 +0200, Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Seemingly the commit caused some issues which should be fixed with the following. AFAICS the patch has landed in master, but I'm not sure if your work is based on top of it or not. http://lists.freedesktop.org/archives/mesa-dev/2014-August/066917.html Cheers, Emil Reverting this commit fixes the problem for us. The revert also fixes piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge [3]. So the question is whether the commit mentioned above introduces a regression that should be fixed somewhere or if our code needs to be updated to adapt to changes introduced by that commit in some way. Best regards, Sam [0] http://lists.freedesktop.org/archives/mesa-dev/2014-August/065692.html [1] https://github.com/samuelig/mesa/tree/gs-support-snb-for-submission-02092014 [2] commit 2f28a0dc23165123cf1e8b5942acad37878edd8a Author: Kristian Høgsberg k...@bitplanet.net Date: Mon Jul 7 16:44:58 2014 -0700 i965: Implement fast color clears using meta operations This patch uses the infrastructure put in place by previous patches to implement fast color clears and replicated color clears in terms of meta operations. This works all the way back to gen7 where fast clear was introduced and adds support for fast clear on gen8. It replaces the blorp path completely and improves on a few cases. Layered clears are now done using instanced rendering and multiple render-target clears use a MRT shader with rep16 writes. Signed-off-by: Kristian Høgsberg k...@bitplanet.net Acked-by: Kenneth Graunke kenn...@whitecape.org [3] http://people.igalia.com/siglesias/mesa/all-gs-patches-v2/changes.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations
On 2014-09-02 18:58, Emil Velikov wrote: Hi Samuel, On 02/09/14 17:22, Samuel Iglesias Gonsálvez wrote: Adding Kristian in Cc. Sam On Tue, 2014-09-02 at 18:16 +0200, Samuel Iglesias Gonsálvez wrote: Hello, Two weeks ago, Iago and myself sent a batch of patches that added geometry shader support for SandyBridge [0]. Recently, we rebased our patches against master [1] and found that some things are not working properly any more. Particularly, we have plenty of cases where we only get a black screen when using a geometry shader, and in these cases it seems as if some outputs of the geometry shader got lost by the time they become inputs in the fragment shader (some input varyings in the fragment shader that come from the outputs of the geometry seem to be zeroed). The values we output in the geometry shader are correct though, since they are correctly captured by transform feedback. A bisect shows that the commit that introduced this problem is 2f28a0dc231 i965: Implement fast color clears using meta operations [2]. Seemingly the commit caused some issues which should be fixed with the following. AFAICS the patch has landed in master, but I'm not sure if your work is based on top of it or not. http://lists.freedesktop.org/archives/mesa-dev/2014-August/066917.html Yes, we rebased the patches on top of today's master (5a4e0f3) which also has the commit you mention. Sam ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
