[Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.

[Paul Berry]

On 11 October 2013 05:43, Mike Lothian <mike at fireburn.co.uk> wrote:

> Well done on getting this enabled
>
> Out of interest how far is SandyBridge from 3.2?
>

I believe geometry shaders are all we would have to implement for Sandy
Bridge.  Unfortunately, geometry shaders work pretty differently on Sandy
Bridge, so getting them to work won't be a slam dunk.  Here's roughly what
would have to be done:

1. Start using Ivy Bridge/Haswell's "single dispatch" mode for geometry
shaders--this mode is more similar to how geometry shaders work on Sandy
Bridge than the "dual object dispatch" mode we're currently using.  In
addition to paving the way for Sandy Bridge geometry shader sepport, there
are additional reasons why this is worth doing on Ivy Bridge and Haswell:
(a) it reduces register pressure, so it should yield better performance for
geometry shaders that would otherwise run out of registers, and (b) it
overlaps a lot with implementing instanced geometry shaders, a feature
required by ARB_gpu_shader5.

2. Ivy Bridge has fixed function hardware to buffer the geometry shader
outputs, decompose strips, and deliver the resulting primitives down the
pipeline one at a time.  Sandy Bridge doesn't, so we'll need to adapt the
shader compilerback end to generate code that does this manually.

3. Ivy Bridge has fixed function hardware to do transform feedback.  Sandy
Bridge doesn't; instead the driver generates an ad hoc geometry shader
program to do transform feedback when it's needed.  When there's a
user-supplied geometry shader, this ad-hoc program will need to get merged
together with the user-supplied shader.

4. Once all that is done, it should be fairly straightforward to emit the
correct 3DSTATE_GS packet to turn on the geometry shader.

I'm hoping I can get to #1 fairly soon (perhaps in December).  I'm not sure
when (or if) I'll have time to work on the others.  It will depend on how
Intel management decides to set my priorities. If anyone out in the
community is interested in contributing to the Sandy Bridge geometry shader
effort, I'd be delighted to collaborate.

Cheers
>
> Mike
> On 11 Oct 2013 05:28, "Paul Berry" <stereotype441 at gmail.com> wrote:
>
>> It's been a long and rocky road, but geometry shader support in Mesa's
>> i965/gen7 driver has finally reached a point I'm willing to call
>> "feature complete".  Since geometry shaders were the last remaining
>> feature needed for GL 3.2, it's time to turn on GL 3.2 support.  Here
>> is a short patch series to turn it on.
>>
>> Patch 1 enables GLSL 1.50 and GL 3.2 for i965/gen7 parts (Ivy Bridge
>> and Haswell).  Patch 2 removes the old warning message "Geometry
>> shader support is currently experimental".  Patch 3 bumps the Mesa
>> major version from 9 to 10 to reflect the fact that we now support a
>> new version of OpenGL.
>>
>> Note: although geometry shaders are feature complete, there are still
>> a few bugs that I still need to iron out before the next release.
>> Here is a list of all the current GLSL 1.50 and GL 3.2 piglit failures
>> on Ivy Bridge and Haswell.  With a few minor exceptions that are
>> unfixable due to hardware limitations, or which are too obscure to be
>> worth fixing, I believe I can take care of all of these by the Nov 27
>> release date.
>>
>> OpenGL 3.2 piglit failures:
>> --------------------------
>>
>> - layered-rendering/clear-{color,depth}: It appears that our glClear
>>   implementation doesn't clear all layers of a layered attachment.
>>
>> -
>> layered-rendering/{framebuffer-layered-attachments,framebuffertexture-defaults}:
>>   I have not investigated, but I believe Jordan Justen may be working
>>   on this.
>>
>> - minmax: GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS has the wrong value.
>>
>> GLSL 1.50 piglit failures:
>> -------------------------
>>
>> - built-in constants/* (9 failures) and compiler/constants.geom: a few
>>   new GLSL 1.50 built-in constants aren't being set up properly.
>>
>> -
>> compiler/{vs,gs}-redeclares-pervertex-out-{after,after-other,before}-global-redeclaration.geom:
>>   We're not flagging an error if both gl_PerVertex and one of its
>>   members are redeclared.
>>
>> -
>> compiler/incorrect-{in,out}-layout-qualifiers-with-variable-declarations.geom:
>>   We're not flagging an error if GS layout qualifiers are improperly
>>   applied to variables.
>>
>> - compiler/interface-blocks-name-reused-globally.vert: We're not
>>   flagging an error if an interface block name conflicts with a global
>>   variable name.
>>
>> - compiler/interface-blocks-structs-defined-within-block-instanced.vert:
>>   We're not flagging an error if a struct is defined inside an
>>   interface block.
>>
>> - compiler/layout-fs-no-output.frag: We're not flagging an error if GS
>>   layout qualifiers are used in a non-geometry shader.
>>
>> - compiler/layout-not-case-sensitive-{in,max-vert,out}.geom and
>>   compiler/layout-not-case-sensitive.frag: Layout qualifiers should be
>>   case-insensitive--they are not.
>>
>> - compiler/layout-vs-no-{input,output}.vert: We're not flagging an
>>   error if GS layout qualifiers are used in a non-geometry shader.
>>
>> - execution/geometry/clip-distance-bulk-copy: Test is broken.  I have
>>   a patch on the Piglit list to fix this.
>>
>> - execution/geometry/triangle-strip-orientation (Ivy Bridge only):
>>   Vertices in triangle strips are improperly ordered.  I am working on
>>   a fix for this.
>>
>> - glsl-1.50-geometry-primitive-id-restart GL_POINTS other (Ivy Bridge
>>   only): A hardware workaround is required.  I am working on a fix for
>>   this.
>>
>> - glsl-1.50-geometry-primitive-types * (10 failures): Failing due to
>>   bugs in transform feedback (I accidentally dropped a patch from
>>   Bryan Cain's original geometry shader series).  I am working on a
>>   fix for this.
>>
>> - glsl-1.50-geometry-tri-strip-ordering-with-prim-restart * (4
>>   failures): Vertices in triangle strips are improperly ordered.  I am
>>   working on a fix for this.
>>
>> -
>> linker/interstage-{pervertex,pervertex-in,pervertex-out}-redeclaration-unneeded:
>>   We're not accounting for the fact that a compilation unit is not
>>   required to redeclare gl_PerVertex if it does not use it.
>>
>> - query-gs-prim-types: New geometry shader informational queries are
>>   not implemented yet.
>>
>> [PATCH 1/3] i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.
>> [PATCH 2/3] mesa: Remove warning that geometry shader support is
>> experimental.
>> [PATCH 3/3] mesa: Bump version to 10.0.0.
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131011/c42aba93/attachment-0001.html>