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. >> > > I don't see that as an issue. First and foremost, TGSI is part of > gallium, which itself makes no binary compatibility guarantees from one > build to the next. In terms of tracing and replay, or any other use of > TGSI to communicate shaders between components that weren't necessarily > built at the same time, then yes a version number would be nice. But > those shaders won't exist in isolation and the rest of the 3d commands & > state will need to establish compatibility. > > It's not the job of the shader representation to do versioning between > two gallium-speaking entities. > > >From that point of view I'm really not sure what the purpose of the > version number, is in our representation, unless we want to be able to > support multiple versions of TGSI simultaneously in one gallium > instance. > > And in turn, I can't really think why we'd want to do that... > > So -- lets remove the version token while we're here. > > One scenario is a sanity check done in the gallium driver. Check if version number matches (exact match) -- there can be changes in the interface that do not break builds. No fancy major.minor versioning schemes, just a number incremented each time we change something in p_shader_tokens.
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
