On 29 January 2013 16:02, Dave Airlie <airl...@gmail.com> wrote: > On Wed, Jan 30, 2013 at 4:44 AM, Paul Berry <stereotype...@gmail.com> > wrote: > > On 29 January 2013 09:33, Ian Romanick <i...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
