Jerome Glisse wrote: > How storing state will done is yet to be determined but the idea is that > finding state with a given id would have to be fast, very fast. Each > state class will have at much 64dword and i think that there will be > somethings around 30 differents class so this isn't much memory and all. > And i don't expect to have more 100 entries per class, at least if i have > more then this class idea is wastefull and i will go the way of reuploading > all state each time. > > Btw, this will be stored in system memory as there storing them in vram > would kill performance (the cmd are submited through system memory though i > think we can use vram). > > Right now my target cards are r300, r400, r500 so all of them have > quite enough memory. That being said the infrastructure for supporting > older card is there and most of initialization code should work on > older card (down to r100) haven't tested yet but will do when i see > the need. >
I fail to see the benefits of doing that sort of inter-client optimization too. Or rather, I think you're trying to solve a problem which probably doesn't exist, and thus just add unnecessary complexity. There is some state which will be different anyway always between two clients (for instance because all your buffer addresses will be different), and quite a lot of other state is changing a lot anyway all the time even within one application (hence you excluded shaders yourself from this scheme, which are a pretty big junk already now and even more so in the future) . And, if some state is really the same between two clients, maybe it's just because noone has changed it really from the default but in this case it might not be relevant at all and you should just rather avoid uploading it in the first place (as a simplified example, something like fog color if fog isn't enabled). I'd agree though that the current state management isn't really ideal, the grouping of state probably not optimal (and state is never reused). Nothing gallium3D couldn't fix :-). Roland ------------------------------------------------------------------------- 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
