Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga wrote: > Hi, > > this series brings support for geometry shaders in Sandy Bridge (gen6) and is > combined work from Samuel and myself. A few notes: > > 1.- Some patches have been based on original work by Ilia Mirkin, specifically > the idea of using arrays to buffer the output of the GS, subclassing the > vec4_gs_visitor for gen6 and generalizing emit_urb_slot(). > > 2.- Geometry shaders were already being used in gen6 to implement transform > feedback support for vertex shaders. We have not changed this. These patches > focus on adding support for user-provided geometry shaders and transform > feedback support for the geometry shader stage. In the future it probably > makes sense to merge transform feedback support for the vertex shader stage > in our implementation so there is only one code path for geometry shaders > in gen6, but it is probably better to tackle that at a later moment, once we > have merged this work. > > 2.- On Ivy Bridge there are no piglit regressions. > > 3.- On Sandy Bridge we get these results after enabling OpenGL 3.2 and > GLSL 1.50 (*1): > > crash:+0 > fail:+15 (*2) > pass: +3265 > skip: -3280 Maybe a list of the failures? Or posting the piglit comparison results might be helpful. For example: http://people.freedesktop.org/~kwg/stuff/bdw-2014-05-13/summary/regressions.html This is not really a big deal, but it would just be nice to quickly see what tests are failing. > (*1) Including Jordan's patches from the series > "Gen6 render surface state changes" since these are required to enable > layered rendering in geometry shaders. The numbers were obtained by comparing > master with Jordan's patches on top (OpenGL 3.1, GLSL 1.40) against master > with these and Jordan's patches on top (OpenGL 3.2, GLSL 1.50) I finally pushed my gen6-layered series to master. (a1dca70) I wonder if you might push these patches to a publicly available branch? Thanks! -Jordan > (*2) These are mostly tests that either fail in Ivy Bridge too, are GS > variants of tests that also fail for the VS/FS stages or relate to other > aspects of OpenGL 3.2 that are not related with geometry shaders. > > 4.- With these patches, the following piglit test hangs: > bin/glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY > > This problem seems to be unrelated to our implementation, since the hang > happens only for that primitive type, only when using glDrawElements() > (so glDrawArrays works fine), and only in specific cases where the list > of indices provided includes repeated indices with a certain pattern. > Actually, > this test hangs even if we have a geometry shader that does nothing (i.e. an > empty main function), where the code we generate is trivial and works with > any other primitive type. Based on this, I conclude that this is a problem > originating somewhere else, I think probably a hardware bug. Because of this, > piglit runs with these patches should exclude this test by including > "-x primitive-id-restart". The offending piglit test can be trivially reworked > to avoid repeating indices in the call to glDrawElements() too. I'll > develop this issue further in another thread so we can decide what to do about > this problem. > > I'll be on holidays for the next two weeks, starting tomorrow, but Samuel will > be around since Tuesday next week so he can start acting on the review > feedback > we get. > > A quick summary of the patches: > > - Patch 1: is actually about gen7, but since gen6's dispatch mode for geometry > shaders is equivalent to gen7's SINGLE mode it makes sense to do this first. > - Patches 2-4 refactor 3DSTATE_GS to accomodate the code path for > user-provided > geometry shaders while keeping the original code that handles TF support > in vertex shaders. > - Patches 5-13 implement generator opcodes, configure state packets and > handle required URB space. > - Patches 14-15 generalize emit_urb_slot() so we can reuse that code. > - Patches 16-19 are the gen6 geometry shader visitor implementation. > - Patches 20-21 implement gl_PrimitiveIDIn. > - Patch 22 makes sure we compute the right VUE map for user-provided GS. > - Patch 23 enables texture related functions in the GS stage. > - Patches 24-33 mostly implement transform feedback > - Patch 34 handles uploading of ubo and pull constant surfaces > - Patch 35 makes gen6 use this implementation of geometry shaders > - Patches 36-37 enable GLSL 1.5 and OpenGL 3.2 in gen6 > > Iago Toral Quiroga (23): > i965/gs: Use single dispatch mode as fallback to dual object mode when > possible. > i965/gen6/gs: Setup constant push buffers for gen6 geometry shaders. > i965/gen6/gs: Implement GS_OPCODE_FF_SYNC. > i965/gen6/gs: Implement GS_OPCODE_URB_WRITE_ALLOCATE. > i965/gen6/gs: Add instruction URB flags to geometry shaders EOT > message. > i965/gen6/gs: Compute URB entry size for user-provided geometry > shaders. > i965
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
El 2014-08-16 09:11, Jordan Justen escribió: On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga wrote: Hi, this series brings support for geometry shaders in Sandy Bridge (gen6) and is combined work from Samuel and myself. A few notes: 1.- Some patches have been based on original work by Ilia Mirkin, specifically the idea of using arrays to buffer the output of the GS, subclassing the vec4_gs_visitor for gen6 and generalizing emit_urb_slot(). 2.- Geometry shaders were already being used in gen6 to implement transform feedback support for vertex shaders. We have not changed this. These patches focus on adding support for user-provided geometry shaders and transform feedback support for the geometry shader stage. In the future it probably makes sense to merge transform feedback support for the vertex shader stage in our implementation so there is only one code path for geometry shaders in gen6, but it is probably better to tackle that at a later moment, once we have merged this work. 2.- On Ivy Bridge there are no piglit regressions. 3.- On Sandy Bridge we get these results after enabling OpenGL 3.2 and GLSL 1.50 (*1): crash:+0 fail:+15 (*2) pass: +3265 skip: -3280 Maybe a list of the failures? Or posting the piglit comparison results might be helpful. For example: http://people.freedesktop.org/~kwg/stuff/bdw-2014-05-13/summary/regressions.html This is not really a big deal, but it would just be nice to quickly see what tests are failing. (*1) Including Jordan's patches from the series "Gen6 render surface state changes" since these are required to enable layered rendering in geometry shaders. The numbers were obtained by comparing master with Jordan's patches on top (OpenGL 3.1, GLSL 1.40) against master with these and Jordan's patches on top (OpenGL 3.2, GLSL 1.50) I finally pushed my gen6-layered series to master. (a1dca70) I wonder if you might push these patches to a publicly available branch? Thanks! -Jordan Sure. Samuel, can you do this? Iago (*2) These are mostly tests that either fail in Ivy Bridge too, are GS variants of tests that also fail for the VS/FS stages or relate to other aspects of OpenGL 3.2 that are not related with geometry shaders. 4.- With these patches, the following piglit test hangs: bin/glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY This problem seems to be unrelated to our implementation, since the hang happens only for that primitive type, only when using glDrawElements() (so glDrawArrays works fine), and only in specific cases where the list of indices provided includes repeated indices with a certain pattern. Actually, this test hangs even if we have a geometry shader that does nothing (i.e. an empty main function), where the code we generate is trivial and works with any other primitive type. Based on this, I conclude that this is a problem originating somewhere else, I think probably a hardware bug. Because of this, piglit runs with these patches should exclude this test by including "-x primitive-id-restart". The offending piglit test can be trivially reworked to avoid repeating indices in the call to glDrawElements() too. I'll develop this issue further in another thread so we can decide what to do about this problem. I'll be on holidays for the next two weeks, starting tomorrow, but Samuel will be around since Tuesday next week so he can start acting on the review feedback we get. A quick summary of the patches: - Patch 1: is actually about gen7, but since gen6's dispatch mode for geometry shaders is equivalent to gen7's SINGLE mode it makes sense to do this first. - Patches 2-4 refactor 3DSTATE_GS to accomodate the code path for user-provided geometry shaders while keeping the original code that handles TF support in vertex shaders. - Patches 5-13 implement generator opcodes, configure state packets and handle required URB space. - Patches 14-15 generalize emit_urb_slot() so we can reuse that code. - Patches 16-19 are the gen6 geometry shader visitor implementation. - Patches 20-21 implement gl_PrimitiveIDIn. - Patch 22 makes sure we compute the right VUE map for user-provided GS. - Patch 23 enables texture related functions in the GS stage. - Patches 24-33 mostly implement transform feedback - Patch 34 handles uploading of ubo and pull constant surfaces - Patch 35 makes gen6 use this implementation of geometry shaders - Patches 36-37 enable GLSL 1.5 and OpenGL 3.2 in gen6 Iago Toral Quiroga (23): i965/gs: Use single dispatch mode as fallback to dual object mode when possible. i965/gen6/gs: Setup constant push buffers for gen6 geometry shaders. i965/gen6/gs: Implement GS_OPCODE_FF_SYNC. i965/gen6/gs: Implement GS_OPCODE_URB_WRITE_ALLOCATE. i965/gen6/gs: Add instruction URB flags to geometry shaders EOT message. i965/gen6/gs: Compute URB entry size for user-provided geometry shaders. i965/gen6/gs: Enable URB space for
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Wed, 2014-08-20 at 11:16 +0200, Iago Toral wrote: > El 2014-08-16 09:11, Jordan Justen escribió: > > On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga > > wrote: > >> Hi, > >> > >> this series brings support for geometry shaders in Sandy Bridge (gen6) > >> and is > >> combined work from Samuel and myself. A few notes: > >> > >> 1.- Some patches have been based on original work by Ilia Mirkin, > >> specifically > >> the idea of using arrays to buffer the output of the GS, subclassing > >> the > >> vec4_gs_visitor for gen6 and generalizing emit_urb_slot(). > >> > >> 2.- Geometry shaders were already being used in gen6 to implement > >> transform > >> feedback support for vertex shaders. We have not changed this. These > >> patches > >> focus on adding support for user-provided geometry shaders and > >> transform > >> feedback support for the geometry shader stage. In the future it > >> probably > >> makes sense to merge transform feedback support for the vertex shader > >> stage > >> in our implementation so there is only one code path for geometry > >> shaders > >> in gen6, but it is probably better to tackle that at a later moment, > >> once we > >> have merged this work. > >> > >> 2.- On Ivy Bridge there are no piglit regressions. > >> > >> 3.- On Sandy Bridge we get these results after enabling OpenGL 3.2 and > >> GLSL 1.50 (*1): > >> > >> crash:+0 > >> fail:+15 (*2) > >> pass: +3265 > >> skip: -3280 > > > > Maybe a list of the failures? Or posting the piglit comparison results > > might be helpful. > > > > For example: > > http://people.freedesktop.org/~kwg/stuff/bdw-2014-05-13/summary/regressions.html > > > > This is not really a big deal, but it would just be nice to quickly > > see what tests are failing. > > > >> (*1) Including Jordan's patches from the series > >> "Gen6 render surface state changes" since these are required to enable > >> layered rendering in geometry shaders. The numbers were obtained by > >> comparing > >> master with Jordan's patches on top (OpenGL 3.1, GLSL 1.40) against > >> master > >> with these and Jordan's patches on top (OpenGL 3.2, GLSL 1.50) > > > > I finally pushed my gen6-layered series to master. (a1dca70) > > > > I wonder if you might push these patches to a publicly available > > branch? > > > > Thanks! > > > > -Jordan > > Sure. Samuel, can you do this? Sure! The public branch with the submitted patches rebased on top of yesterday's master is here: https://github.com/samuelig/mesa/tree/gs-support-snb-for-submission And the piglit comparison between yesterday's master which already have Jordan's patches in SNB (OpenGL 3.1, GLSL 1.40) and our patches (OpenGL 3.2, GLSL 1.50) is here: http://samuelig.es/mesa-dev/all-submitted-patches-19-aug/ Sorry for the delay, uploading the whole piglit's HTML output is taking a lot of time with my Internet connection :-S If you find that some files are missing just try again later (FTP transfer is still uploading files). Best regards, Samuel 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] [PATCH 00/37] Geometry shader support in Sandy Bridge
On 20 August 2014 11:18, Samuel Iglesias Gonsálvez wrote: > On Wed, 2014-08-20 at 11:16 +0200, Iago Toral wrote: >> El 2014-08-16 09:11, Jordan Justen escribió: >> > On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga >> > wrote: >> >> Hi, >> >> >> >> this series brings support for geometry shaders in Sandy Bridge (gen6) >> >> and is >> >> combined work from Samuel and myself. A few notes: >> >> >> >> 1.- Some patches have been based on original work by Ilia Mirkin, >> >> specifically >> >> the idea of using arrays to buffer the output of the GS, subclassing >> >> the >> >> vec4_gs_visitor for gen6 and generalizing emit_urb_slot(). >> >> >> >> 2.- Geometry shaders were already being used in gen6 to implement >> >> transform >> >> feedback support for vertex shaders. We have not changed this. These >> >> patches >> >> focus on adding support for user-provided geometry shaders and >> >> transform >> >> feedback support for the geometry shader stage. In the future it >> >> probably >> >> makes sense to merge transform feedback support for the vertex shader >> >> stage >> >> in our implementation so there is only one code path for geometry >> >> shaders >> >> in gen6, but it is probably better to tackle that at a later moment, >> >> once we >> >> have merged this work. >> >> >> >> 2.- On Ivy Bridge there are no piglit regressions. >> >> >> >> 3.- On Sandy Bridge we get these results after enabling OpenGL 3.2 and >> >> GLSL 1.50 (*1): >> >> >> >> crash:+0 >> >> fail:+15 (*2) >> >> pass: +3265 >> >> skip: -3280 >> > >> > Maybe a list of the failures? Or posting the piglit comparison results >> > might be helpful. >> > >> > For example: >> > http://people.freedesktop.org/~kwg/stuff/bdw-2014-05-13/summary/regressions.html >> > >> > This is not really a big deal, but it would just be nice to quickly >> > see what tests are failing. >> > >> >> (*1) Including Jordan's patches from the series >> >> "Gen6 render surface state changes" since these are required to enable >> >> layered rendering in geometry shaders. The numbers were obtained by >> >> comparing >> >> master with Jordan's patches on top (OpenGL 3.1, GLSL 1.40) against >> >> master >> >> with these and Jordan's patches on top (OpenGL 3.2, GLSL 1.50) >> > >> > I finally pushed my gen6-layered series to master. (a1dca70) >> > >> > I wonder if you might push these patches to a publicly available >> > branch? >> > >> > Thanks! >> > >> > -Jordan >> >> Sure. Samuel, can you do this? > > Sure! > > The public branch with the submitted patches rebased on top > of yesterday's master is here: > > https://github.com/samuelig/mesa/tree/gs-support-snb-for-submission > > And the piglit comparison between yesterday's master which already have > Jordan's patches in SNB (OpenGL 3.1, GLSL 1.40) and our patches > (OpenGL 3.2, GLSL 1.50) is here: > > http://samuelig.es/mesa-dev/all-submitted-patches-19-aug/ > > Sorry for the delay, uploading the whole piglit's HTML output is taking > a lot of time with my Internet connection :-S If you find that some > files are missing just try again later (FTP transfer is still uploading > files). > > Best regards, > > Samuel > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however when I run Heaven 4 I get a blank screen when rendering and the following messages: GLFrameBuffer::enable(): incomplete attachment GLFrameBuffer::enable(): incomplete attachment GLFrameBuffer::enable(): incomplete attachment GLFrameBuffer::enable(): incomplete attachment OpenGL error: invalid framebuffer operation This only happens when at 8xAA - is the demo mis detecting the AA abilities of Sandybridge? Valley seem to have rendering issues no matter what the AA level - I get black trees in the foreground With Oil Rush I always get white game rendering (the overlays are fine) no matter what the AA level Metro Last Light seems to play fine even at the highest levels ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Wed, Aug 20, 2014 at 4:30 PM, Mike Lothian wrote: > Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however > when I run Heaven 4 I get a blank screen when rendering and the > following messages: > > GLFrameBuffer::enable(): incomplete attachment > GLFrameBuffer::enable(): incomplete attachment > GLFrameBuffer::enable(): incomplete attachment > GLFrameBuffer::enable(): incomplete attachment > OpenGL error: invalid framebuffer operation > > This only happens when at 8xAA - is the demo mis detecting the AA > abilities of Sandybridge? Sounds like it. Sandybridge can only do 4x MSAA. > Valley seem to have rendering issues no matter what the AA level - I > get black trees in the foreground Possibly need some workaround. Can't remember. > With Oil Rush I always get white game rendering (the overlays are > fine) no matter what the AA level This sounds like the problem where their shaders put #extension in the wrong place. Try running with MESA_EXTENSION_OVERRIDE=-GL_ARB_sample_shading. I think there's a driconf for this now. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On 21 August 2014 00:41, Matt Turner wrote: > On Wed, Aug 20, 2014 at 4:30 PM, Mike Lothian wrote: >> Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however >> when I run Heaven 4 I get a blank screen when rendering and the >> following messages: >> >> GLFrameBuffer::enable(): incomplete attachment >> GLFrameBuffer::enable(): incomplete attachment >> GLFrameBuffer::enable(): incomplete attachment >> GLFrameBuffer::enable(): incomplete attachment >> OpenGL error: invalid framebuffer operation >> >> This only happens when at 8xAA - is the demo mis detecting the AA >> abilities of Sandybridge? > > Sounds like it. Sandybridge can only do 4x MSAA. Hmm mis detecting or is the driver mis advertising? > >> Valley seem to have rendering issues no matter what the AA level - I >> get black trees in the foreground > > Possibly need some workaround. Can't remember. > >> With Oil Rush I always get white game rendering (the overlays are >> fine) no matter what the AA level > > This sounds like the problem where their shaders put #extension in the > wrong place. Try running with > MESA_EXTENSION_OVERRIDE=-GL_ARB_sample_shading. I think there's a > driconf for this now. Yes that fixed the Oil Rush one - I don't need to pass that with r600g though so I'm thinking that maybe i965 isn't using that driconf file ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Wed, Aug 20, 2014 at 4:49 PM, Mike Lothian wrote: > On 21 August 2014 00:41, Matt Turner wrote: >> On Wed, Aug 20, 2014 at 4:30 PM, Mike Lothian wrote: >>> Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however >>> when I run Heaven 4 I get a blank screen when rendering and the >>> following messages: >>> >>> GLFrameBuffer::enable(): incomplete attachment >>> GLFrameBuffer::enable(): incomplete attachment >>> GLFrameBuffer::enable(): incomplete attachment >>> GLFrameBuffer::enable(): incomplete attachment >>> OpenGL error: invalid framebuffer operation >>> >>> This only happens when at 8xAA - is the demo mis detecting the AA >>> abilities of Sandybridge? >> >> Sounds like it. Sandybridge can only do 4x MSAA. glxinfo -l | grep GL_MAX_SAMPLES will tell you. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On 21 August 2014 00:58, Matt Turner wrote: > On Wed, Aug 20, 2014 at 4:49 PM, Mike Lothian wrote: >> On 21 August 2014 00:41, Matt Turner wrote: >>> On Wed, Aug 20, 2014 at 4:30 PM, Mike Lothian wrote: Hi I tested the branch - glxinfo reports GL 3.2 and GLSL 1.50 however when I run Heaven 4 I get a blank screen when rendering and the following messages: GLFrameBuffer::enable(): incomplete attachment GLFrameBuffer::enable(): incomplete attachment GLFrameBuffer::enable(): incomplete attachment GLFrameBuffer::enable(): incomplete attachment OpenGL error: invalid framebuffer operation This only happens when at 8xAA - is the demo mis detecting the AA abilities of Sandybridge? >>> >>> Sounds like it. Sandybridge can only do 4x MSAA. > > glxinfo -l | grep GL_MAX_SAMPLES > > will tell you. It does indeed report 4 - must be a general bug of Unigine then ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Thu, 21 Aug 2014 01:49:06 +0200, Mike Lothian wrote: Yes that fixed the Oil Rush one - I don't need to pass that with r600g though so I'm thinking that maybe i965 isn't using that driconf file ___ r600g doesn't have support for GL_ARB_sample_shading quite just yet which is why it doesn't complain. If you copy a current git src/mesa/drivers/dri/common/drirc file to /etc/drirc it contains the settings needed to work around a few Unigine buglets. The "allow_glsl_extension_directive_midshader" directive is hooked up both for gallium and intel afaik so should just work. /Glenn ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Wed, Aug 20, 2014 at 3:18 AM, Samuel Iglesias Gonsálvez wrote: > On Wed, 2014-08-20 at 11:16 +0200, Iago Toral wrote: >> El 2014-08-16 09:11, Jordan Justen escribió: >> > On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga >> > wrote: >> >> Hi, >> >> >> >> this series brings support for geometry shaders in Sandy Bridge (gen6) >> >> and is >> >> combined work from Samuel and myself. A few notes: >> >> >> >> 1.- Some patches have been based on original work by Ilia Mirkin, >> >> specifically >> >> the idea of using arrays to buffer the output of the GS, subclassing >> >> the >> >> vec4_gs_visitor for gen6 and generalizing emit_urb_slot(). >> >> >> >> 2.- Geometry shaders were already being used in gen6 to implement >> >> transform >> >> feedback support for vertex shaders. We have not changed this. These >> >> patches >> >> focus on adding support for user-provided geometry shaders and >> >> transform >> >> feedback support for the geometry shader stage. In the future it >> >> probably >> >> makes sense to merge transform feedback support for the vertex shader >> >> stage >> >> in our implementation so there is only one code path for geometry >> >> shaders >> >> in gen6, but it is probably better to tackle that at a later moment, >> >> once we >> >> have merged this work. >> >> >> >> 2.- On Ivy Bridge there are no piglit regressions. >> >> >> >> 3.- On Sandy Bridge we get these results after enabling OpenGL 3.2 and >> >> GLSL 1.50 (*1): >> >> >> >> crash:+0 >> >> fail:+15 (*2) >> >> pass: +3265 >> >> skip: -3280 No piglit regressions were reported on gen8 with the samuelig/gs-support-snb-for-submission-02092014 branch. -Jordan >> > >> > Maybe a list of the failures? Or posting the piglit comparison results >> > might be helpful. >> > >> > For example: >> > http://people.freedesktop.org/~kwg/stuff/bdw-2014-05-13/summary/regressions.html >> > >> > This is not really a big deal, but it would just be nice to quickly >> > see what tests are failing. >> > >> >> (*1) Including Jordan's patches from the series >> >> "Gen6 render surface state changes" since these are required to enable >> >> layered rendering in geometry shaders. The numbers were obtained by >> >> comparing >> >> master with Jordan's patches on top (OpenGL 3.1, GLSL 1.40) against >> >> master >> >> with these and Jordan's patches on top (OpenGL 3.2, GLSL 1.50) >> > >> > I finally pushed my gen6-layered series to master. (a1dca70) >> > >> > I wonder if you might push these patches to a publicly available >> > branch? >> > >> > Thanks! >> > >> > -Jordan >> >> Sure. Samuel, can you do this? > > Sure! > > The public branch with the submitted patches rebased on top > of yesterday's master is here: > > https://github.com/samuelig/mesa/tree/gs-support-snb-for-submission > > And the piglit comparison between yesterday's master which already have > Jordan's patches in SNB (OpenGL 3.1, GLSL 1.40) and our patches > (OpenGL 3.2, GLSL 1.50) is here: > > http://samuelig.es/mesa-dev/all-submitted-patches-19-aug/ > > Sorry for the delay, uploading the whole piglit's HTML output is taking > a lot of time with my Internet connection :-S If you find that some > files are missing just try again later (FTP transfer is still uploading > files). > > Best regards, > > Samuel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Thursday, August 14, 2014 01:11:32 PM Iago Toral Quiroga wrote: > Hi, > > this series brings support for geometry shaders in Sandy Bridge (gen6) and is > combined work from Samuel and myself. I've looked over most of the series, and everything looks good (though I didn't have time to look at it in as much detail as I'd hoped). It sounds like Jordan's reviewed quite a bit of it. Feel free to add my ack on the series: Acked-by: Kenneth Graunke I think you're probably good to push it at this point. Fantastic work, as always :) 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] [PATCH 00/37] Geometry shader support in Sandy Bridge
On mar, 2014-09-16 at 01:09 -0700, Kenneth Graunke wrote: > On Thursday, August 14, 2014 01:11:32 PM Iago Toral Quiroga wrote: > > Hi, > > > > this series brings support for geometry shaders in Sandy Bridge (gen6) and > > is > > combined work from Samuel and myself. > > I've looked over most of the series, and everything looks good (though I > didn't have time to look at it in as much detail as I'd hoped). It sounds > like Jordan's reviewed quite a bit of it. That's great, thanks Kenneth. I think Jordan only managed to review the first 6 patches so far. > Feel free to add my ack on the series: > > Acked-by: Kenneth Graunke Will do. > > I think you're probably good to push it at this point. Fantastic work, as > always :) Thanks! :) I think Jordan still wanted to review the patches, so I'll wait for his ok before pushing anything. Iago ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Tue, Sep 16, 2014 at 3:07 AM, Iago Toral Quiroga wrote: > On mar, 2014-09-16 at 01:09 -0700, Kenneth Graunke wrote: >> On Thursday, August 14, 2014 01:11:32 PM Iago Toral Quiroga wrote: >> > Hi, >> > >> > this series brings support for geometry shaders in Sandy Bridge (gen6) and >> > is >> > combined work from Samuel and myself. >> >> I've looked over most of the series, and everything looks good (though I >> didn't have time to look at it in as much detail as I'd hoped). It sounds >> like Jordan's reviewed quite a bit of it. > > That's great, thanks Kenneth. I think Jordan only managed to review the > first 6 patches so far. > >> Feel free to add my ack on the series: >> >> Acked-by: Kenneth Graunke > > Will do. > >> >> I think you're probably good to push it at this point. Fantastic work, as >> always :) > > Thanks! :) > > I think Jordan still wanted to review the patches, so I'll wait for his > ok before pushing anything. Sorry. I'll get back to this today. So far, for 7-15 you can add: Reviewed-by: Jordan Justen Ken: Iago seems to have updated "i965/gen6/gs: Implement GS_OPCODE_FF_SYNC." "i965/gen6/gs: Implement GS_OPCODE_SET_DWORD_2." At git://github.com/samuelig/mesa.git on the gs-support-snb-for-submission-02092014 branch based on your suggestions in case you wanted to verify the changes. -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
