Stephane Marchesin wrote:
> Hi,
>
> I was looking at the softpipe code, and it all seems quite interesting.
> However, it came to me that the state code was going overly complex.
> Especially since you have to write a lot of state functions/atoms
> yourself. As with the older DRI code, where most state functions simply
> end up gathering state in the mesa state structs, and filling register
> bits accordingly (this is really all the same, except with different
> mesa values and different register numbers).
> This is 2007, why couldn't mesa handle it generically ?
>
> Now, here is the idea I had. What if instead of creating your own atoms
> by hand, you just described the state as follows :
> - one function that takes a reg number and a value (and possibly a mask)
> as input and does the actual register write
> - an array of structs describing the state at the hw level (for example,
> saying that enabling alpha blending is setting bit 12 in register 0x1234
> and so on for all state)
> I think this model applies to all the graphics hardware that I know of.
>
> What this allows :
> - mesa can merge multiple writes to the same register (for example for
> different states that go to the same register) so this should be more
> efficient
> - the driver code is simpler, since we don't have to write a pile of
> state functions any more (I'm lazy, so that's my main goal)
>
> Ideas ?
The major item right now is that the constant state object code isn't
committed yet. Zack is working on this and is almost done, and it will
change the nature of state handling in Gallium/softpipe in a fairly
major way compared to the code that is currently in git. The changes are:
1) Fewer state objects, probably 5 or 6.
2) The constant state object life cycle, ie:
- CreateBlendState
- BindBlendState
- DestroyBlendState
3) State partitioned in a hopefully sensible way for hardware.
The intended usage will be that the driver's CreateBlendState function
is the only place you have to think about Mesa state, ie the driver does
a one-time-only conversion to hardware format state.
In BindBlendState(), the driver only has to directly emit the
pre-computed values to registers.
This should get most of the benefits you're talking about above.
The biggest issue is - how well does the partitioning of state match the
hardware's state interface.
I'd like to see how the above scheme pans out before starting a more
dynamic approach. But if we wanted to, I think the easiest way to get
*all* the benefits of your approach with reasonable simplicity is to
have the driver actually *define* what items are present in each state
object, and then apply the above lifecycle to the driver-defined objects...
Keith
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
