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