Hi Marek,
On Saturday, May 05, 2012 22:12:51 Marek Olšák wrote:
> could somebody please take a look at this series? It changes a couple
> of things in gl_context and the vbo module.
>
> The other two patches are:
> [PATCH 2/3] mesa: move gl_client_array*[] from vbo_draw_func into gl_context
> [PATCH 3/3] mesa: add gl_context::NewDriverState and use it for vertex
> arrays
I am probably the wrong one to give a architectural ack for the series since I
am only a part time worker in some corners.
But I can tell what I had in mind in this area when I did the last changes.
You are partly heading in the same direction with moving the client array as
state into mesa.
My plan was:
Do draws in terms of a gl_array_object that is active for draw. That would
play the role of your bare client array pointer currently. For the immediate
mode save and exec context code paths we would use a hidden array object that
is used on a drivers call code path. For the OpenGL api's draw arrays we would
use the contexts gl_array_object for draws.
In my plan the client_array should be located in the gl_array_object.
Therefore the NewArray bitfield also moved to gl_array_object recently. You can
then there build up a self contained set of methods on the gl_array_object to
update its state and track the dirty bits in the NewArray bitfield also in
combination with the Enabled bitfield where we can play a lot of tricks with
the bitfields to reduce a lot of loops iterating all 33 arrays with loops only
working on the changed arrays.
For the drivers side I think that we can get rid of the client_array
completely for the gallium side. To do that, I wanted to derive a
st_array_object and a classic_array_object from gl_array_object. The
client_array in its current form could then move into the classic_array_object
where we can still play intelligent games with the bitfields to cut down the
length 33 loops int the fast draw path. But the st_array_object would only
have space for pipe_vertex_{buffer,elements} in addition to the fields from the
base gl_array_object class. These elements could then be incrementally updated
using the NewArray and Enabled bitfields and applied to the gallium state when
needed.
Given that I think that I would prefer to have the client_array (not the
pointer to the first element) itself in the gl_array_object. And the role of
your gl_client_array** pointer would be replaced by a gl_array_object pointer
with the same three instances (drawelements api path, vbo_exec, vbo_save)
around that your patch uses for the *gl_client_array[].
The benefit would be that you could probably encapsulate the the array state
tracking completely into this subobject, track changes using nifty bitfields
using ffs based way smaller loops and only track changes to the gl_array_object
draw pointer at the context toplevel.
So, for my interrest, what are your further plans beyond this change?
Greetings
Mathias
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
