[Mesa-dev] GS plans?

[Paul Berry]

On 29 January 2013 16:02, Dave Airlie <airlied at gmail.com> wrote:

> 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.
>

Thanks, Dave.  I'll be sure to fold that into my plans.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130130/3cf4c408/attachment.html>