[Mesa-dev] GS plans?

[Dave Airlie]

On Wed, Jan 30, 2013 at 4:44 AM, Paul Berry <stereotype441 at gmail.com> wrote:
> On 29 January 2013 09:33, Ian Romanick <idr at freedesktop.org> wrote:
>>
>> On 01/29/2013 09:02 AM, Brian Paul wrote:
>>>
>>>
>>> Hi Bryan,
>>>
>>> Back in July you announced your work on geometry shaders:
>>> http://lists.freedesktop.org/archives/mesa-dev/2012-July/024792.html
>>>
>>> But it looks like it hasn't been touched since October.  I was wondering
>>> what plans you might have for that.
>>>
>>> I believe the Intel guys also were planning on tackling GS support in
>>> Mesa this year.  Ian, Eric, do you have some idea of when you'll be
>>> working on that?  Were you going to use Bryan's work?
>>
>>
>> I believe Paul is going to chip away at a bit of it.  I think he's
>> planning to use some of Bryan's work.  I believe they've been in contact,
>> but I'm not 100% sure.
>>
>
> Yes, we have.  It looks like Bryan made a lot of headway before he set the
> branch aside in October, so I'm planning to use that as a starting point.
> My impression from talking to Bryan is that he doesn't have too much
> time/interest to put into geometry shaders these days, so for the moment I'm
> planning to take over responsibility for the branch myself.
>
> My first order of business is to write some piglit tests for geometry
> shaders, so that I don't have to push anything to Mesa master that isn't
> well-tested.  I have an nVidia system that I can use as a reference platform
> to make sure my tests are correct.  I also want to spend a little bit of
> time prototyping 0some i965 back-end code just to increase my familiarity
> with the problem domain and to find out if i965 hardware has any sharp
> corners I need to watch out for.  Once I've done those two things, my plan
> is to start rebasing Bryan's patch series onto master and sending it out for
> review piece by piece.
>
> Geometry shaders haven't risen to the top of Intel's priority list quite
> yet, but they're letting me work on them part-time for now, so progress is
> likely to be slow for a while.  I'll keep the mailing list updated as to my
> progress.  And I'll try to make sure that major design decisions get
> discussed here on the list so that no one gets left out of the loop.
>

Bryan posted a bit of a todo list on phoronix, I'll reproduce it here,

"Although there are no piglit tests for it yet, my geometry shader
code on GitHub has had a decent amount of stress-testing; I'm not too
concerned about an abundance of bugs in the existing code. Aside from
piglit tests (which are, as you say, the biggest problem), though,
there are a few other things that need to be done:

    The changes will need to be rebased and reformatted into a sane
patch set rather than the current haphazard mix of commits that add
functionality with commits to fix mistakes in previous changes.
    The interactions with FBOs (section "Dependencies on
EXT_framebuffer_object" in the ARB_geometry_shader4 spec) need to be
implemented. This might only be needed for the EXT/ARB extensions and
not core, but with this much work done on the extensions it would be
silly not to support them as well as the core version. It seems that
doing this properly will also require changes to the softpipe driver.
    If it hasn't already been done, the GLSL compiler will need to
implement the core version of the geometry shader language. The main
change is using the "gl_in[]" struct array for input/output instead of
one input array per attribute. This will just require a lowering pass
to lower gl_PerVertex accesses to the 2D array accesses used in the
extension, which can be (and already are) sanely translated to TGSI by
glsl_to_tgsi."

Dave.