[Mesa-dev] [PATCH 1/3] vbo: move vbo_draw_method into vbo_context.h

[Mathias Fröhlich]

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