Keith Whitwell pisze: > On Thu, 2009-11-26 at 10:42 -0800, michal wrote: > >> Keith Whitwell pisze: >> >>> On Wed, 2009-11-25 at 08:51 -0800, michal wrote: >>> >>> >>>> michal pisze: >>>> >>>> >>>>> Keith Whitwell pisze: >>>>> >>>>> >>>>> >>>>>> On Wed, 2009-11-25 at 06:28 -0800, michal wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Keith Whitwell pisze: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I've pushed a feature branch with some tgsi simplifications in it. >>>>>>>> With >>>>>>>> these I've removed the biggest remaining oddities of that language, and >>>>>>>> it's getting to a place where I'm starting to be happy with it as a >>>>>>>> foundation for future work. >>>>>>>> >>>>>>>> Most of the surprising stuff like multiple negate flags, etc, is gone >>>>>>>> now, and the core tokens are quite a bit easier to understand than in >>>>>>>> previous iterations. >>>>>>>> >>>>>>>> I've still got my eye on reducing the verbosity of the names in the >>>>>>>> tgsi_parse.h "FullToken" world, and promoting the tgsi_any_token union >>>>>>>> into p_shader_tokens.h. >>>>>>>> >>>>>>>> It would be good if people can review the interface changes and provide >>>>>>>> feedback, and also test out their drivers on this branch. I've done >>>>>>>> minimal softpipe testing so far but will do more over the next few >>>>>>>> days. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> All looks good to me, I'm happy somebody had the guts to cut off all >>>>>>> the >>>>>>> cruft in one shot. >>>>>>> >>>>>>> I see some compile errors on windows build -- I will fix those along >>>>>>> with other minor bugs I have spotted. >>>>>>> >>>>>>> Now, looking at the interface, I'm thinking about removing some more >>>>>>> tokens. >>>>>>> >>>>>>> 1) Remove tgsi_dimension and use tgsi_src_register directly with some >>>>>>> well-defined constraints. >>>>>>> >>>>>>> 2) Do the same to tgsi_instruction_predicate. Really, it's just an >>>>>>> optional src operand with some restrictions. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Interesting. I'd be keen to see a patch. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Attached. But the more I look at it the more lame it gets. >>>>> >>>>> Another option would be to define tgsi_any_register that would have >>>>> File, Index, Indirect and Dimension fields. Then there would be more >>>>> specialised tgsi_*_register tokens, that would be binary compatible with >>>>> the first one. One could cast them using a union and avoid more mistakes >>>>> at compile time. That way we don't have to put the constraints in >>>>> comments, but be more strict and use the compiler to enforce them. I >>>>> will follow up with a patch. >>>>> >>>>> >>>>> >>>> Attached. >>>> >>>> >>> This makes me wonder about a couple of other things, like whether 16 >>> bits is sufficient for the index value. Probably its fine, but it's not >>> beyond belief to consider a constant buffer of 256k or larger. >>> >>> I'd consider dropping the "generic_register" struct and any idea of a >>> union of these registers. I'm not really sure we want to encourage the >>> idea of people casting between these registers -- for the most part they >>> should be building these things with ureg-style functions rather than >>> messing around with the tokens directly. >>> >>> If you can easily cast between registers, that defeats any static >>> constraints you attempt to impose via the type system, and you may as >>> well just use "src_register" for predicates and dimensions. An >>> interpreter which might benefit from being able to share some code paths >>> for the different registers doesn't need the union to be public. >>> >>> Basically, this looks like a good regularization/cleanup, but let's drop >>> generic_register and not create any public union of these register >>> structs. >>> >>> >>> >> Attached an updated patch. >> >> One thing to note in general is that by removing the Extended flags and >> the fact that some of the tokens already use up all the available 32 >> bits, the only way to extend the language may be by incrementing the >> version number in shader's header. This can be a good or a bad thing, >> depending on the direction Gallium is heading, but with a bit of >> discipline that should be a good thing. >> > > > Michal, > > What's the status of this change? Are you working on building up a full > change based on this patch? > > I'd like to merge this branch sooner rather than later, so if you > haven't got something that's pretty much ready to go, let's handle this > change in a branch of its own. > > Nothing more has been done for it, so go ahead and merge.
------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
