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. 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