Keith Whitwell wrote: > Jerome Glisse wrote: >> Hi all, >> >> While playing with modesetting & ttm i have put some thought on how >> we send >> things to card. And i would like to test the following scheme: >> -split card state into a bunch of separate chunk (z state, fog state, >> ...) >> -the driver build the state it want and register each state chunk to >> the drm >> -drm give an unique id for this state chunk the id have two part one >> is the >> chunk class (z state, fog state, ...) the other is an unique id >> identifying >> this particular state id in the chunk class. These are shared btw >> all drm >> client ie if another program register exact same stage then drm >> return the >> same id >> -driver can no use this id by using superioctl and providing a list >> of state id >> -drm keep a list of lastest state id uploaded to card an upload only >> state chunk >> which differ and update its list of state id >> -few things won't be in this state things like vertex program or >> fragment program >> (i believe that there might be too much different of them that this >> won't be >> efficient to cache which program was lastly uploaded; so i think >> its better to >> reupload program each time (they ain't big anyway). >> >> So what good things do we got with this: >> - from user space its like the card have context :) >> - we can save a lot of state reuploading the assumption being that most >> program share most of the state (ie if state chunk are well sliced >> there won't >> be many different state id in each state class). >> - drm is the only place where we can have a coherent & up to date >> view of >> current state uploaded on card >> - its lot easier than asking for the userspace to resend all its state >> - most of the checking is done at state registration (ain't big win i >> think) >> - in the future we can even schedule request in the order which will >> trigger >> the less number of state change >> >> There is likely others good things on the bright side... >> >> Bad things: >> - backward compat if we want to change how state are sliced or what >> we accept >> or not (i think by cleverly thinking the interface we might >> minimize problems >> in this area) >> - if we badly split state than we might end up having to much id in >> for some >> state chunk which will slow down state registration (as this >> involve searching >> to all previous state of same class see if the states registered >> already exist) >> >> Maybe others bad things ? I think we can work around this by putting >> some time >> into real test usage of this to see how best we can split state & and >> what might >> be cached by state or reuploaded at each call. >> >> So the superioctl will looks like this: >> - drm drawable (where we draw dri 2 world :)) >> - list of state id >> - cmd buffer (cmd stream with vert, frag prog & other state not >> cached by the above >> mechanism) >> - list of reloc buffer >> -reloc pos into the cmd buffer >> -buffer >> >> The list of reloc buffer will be there to supply texture buffer, >> vertex buffer or >> others buffer of this kind. In this scheme you can draw only in one >> context by call >> but this could be extended even though i believe its better that way. >> >> I believe such scheme were already proposed in the past. So what do >> you think >> about it ? I will start soon a sample program (named r300_demo ;)) to >> test this scheme >> before doing any driver works and see how it behave. > > This is more or less extending the constant state object idea as > described by GL3, Gallium3D and other 3D APIs to multiple applications. > > The biggest issue I see is that we expect individual applications to > create a moderately large number of these states and to rapidly switch > between them. > > The likelyhood that two unrelated applications would happen to be > sharing any large number of these at context switch time seems fairly > low. > > Also, for current drivers, the number of context switches compared to > the number of other state changes is actually pretty low. I guess I'd > have to question whether even a very large speed savings in a fairly > rare case (context switch) is going to make a noticable difference > overall. > > I think that this approach makes sense within a driver context - ie as > a way to avoid the same app repeatedly emitting the same piece of > state, hence the thinking behind constant state objects in GL3 and > elsewhere, but maybe less exciting for sharing between unrelated > contexts. > > Keith State i am thinking of are lot smaller and won't have as many possibility. For instance in fog i don't want to cache fog color or in z i don't want to cache z clear color. I am only interested in putting state which have a configuration impact on the card which might need special treatment like waiting for 3d part to go idle or syncing with somethings.
To sum up any of the state class i am thinkng of shouldn't have more than 1000 different possible combinations (and likely a lot less). I need to build some of this class to have an idea on how much different possibilities their might have. Anyway i will experiment with this a bit and see if it makes sense but i really don't want to have which can have too much different values. Cheers, Jerome Glisse ------------------------------------------------------------------------- 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/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
