Gentlemen, let me see if I understand this properly. You want to
create a finite number of states, store them in a list and switch
amongst them on a whim, right? If my understanding is correct, I am
wondering how much data you are going to store in these states, and
how many states you wish to create. I mean, if you have only twenty
states, each containing a few K of data, it doesn't seem like much,
but if you want to put a megabyte in each state, that would restrict
you to 64MB and greater for graphics cards - not really much of an
issue with newer hardware, but there are a few 1MB cards still
floating around in Linux boxes. (I know, I have one or two.) Also,
having a large number of states to sort through might end up degrading
performance if you have to search for the proper state each time,
depending on the fetching algorithm.
These concerns are, of course, purely due to my not understanding what
information you want to store in the state. I can conceive of a
single state which stores all pixel data - hardly useful - all the way
down to one that stores only which VGA mode you are rendering the
image with. Can you point out where in this scale you are working?
Garry
On Nov 19, 2007 4:10 PM, Jerome Glisse [EMAIL PROTECTED] wrote:
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.
