On 31.12.2009 15:55, Keith Whitwell wrote: > On Thu, 2009-12-31 at 05:28 -0800, Christoph Bumiller wrote: > >> On 31.12.2009 12:05, Keith Whitwell wrote: >> >>> Luca, >>> >>> This is an impressive body of work. I want to give Jose a chance to >>> review the EGL/GLX extensions before pushing, but in the meantime I hope >>> it's ok if I make a couple of quick suggestions/requests: >>> >>> Firstly, we're going to be evolving the TGSI instruction set a fair bit >>> over the coming months to catch up with newer GLSL versions, CL, etc. >>> >> At that point I'd like to ask if, when all the nice memory spaces >> are introduced to TGSI, these nasty indirect accesses to TEMP >> will go away. >> >> They are really painful to implement because you cannot index >> registers on nv50+ and thus we'd have to regard TEMP as memory. >> And since there is no information in the TGSI tokens about >> what TEMPs constitute an array, we'd have to store and load >> all of them, which would be quite costly. >> > Yes, I think there will end up being some way in which we mark indexable > ranges of temporaries. > > >> So I was hoping that, optionally (older cards without actual memory >> won't like it I suppose), the compiler can just generate the >> appropriate stores and loads. >> > I'm not sure about that. Can you be more explicit about what you're > having trouble with? > > Keith > > The trouble is mostly that we'd need a proper optimizing compiler to get something performant out of TGSI (I'm still hoping to have time for that nv50+ llvm backend at some point).
If addressable ranges of TEMPs are marked, we can just store the whole range to local memory, emit the indirect store or load, and bring them back to registers (maybe on demand), do some flow analysis to get something better etc. It would be doable. I just thought if these loads/stores were generated by the top level compiler itself there might be more potential for optimization and the pipe driver's compiler could be simpler. Thanks, Christoph. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev