José Fonseca wrote:
> On Sun, 2009-05-03 at 03:05 -0700, Thomas Hellström wrote:
>
>> Jose Fonseca wrote:
>>
>>> gallium-screen-context adds a new callback to create a context with a
>>> screen. This is very useful when one stacks pipe drivers on top of another
>>> (like the trace pipe driver, or perhaps one day the draw module). The
>>> problem is the pipe_context::priv and the context_private argument of
>>> pipe_screen::flush_frontbuffer. Putting private in pipe_context doesn't
>>> work if there are many pipe contexts. Basically, pipe_context::priv must
>>> disappear, and context_private argument must be replaced by something
>>> sensible (perhaps an abstract drawable pointer). However these are used by
>>> GLX/DRI code which I don't understand enough to fix on my own.
>>>
>>>
>>>
>> José,
>>
>> the drm_api <gallium/include/state-tracker/drm_api.h> has an equivalent
>> callback usually exported by a particular winsys wanting to implement
>> the drm_api, and that winsys typically call into the pipe driver to
>> implement this, so having it exported by the pipe_screen is probably a
>> good idea.
>>
>> The problem with pipe_context::priv is that the state-tracker may export
>> a set off callbacks to be used by the winsys, and these callbacks
>> typically take an opaque pointer to a per-context structure used by the
>> state tracker. For DRI these are flush_frontbuffer and the DRI locking
>> functions.
>>
>> One possible solution to this would be to have a
>>
>> pipe_screen::context_create(struct pipe_screen *screen, struct
>> context_private *priv);
>>
>> @priv could either be a void * or perhaps a pointer to a structure that
>> can be derived from:
>>
>> A pipe driver wrapping this function would just pass the priv parameter
>> on to the next level.
>>
>
> Yes, passing priv as an argument is a simple solution that allows to
> move this change forward. I guess that I abhor these magic priv pointers
> so much that I didn't even thought about it.
>
>
Well, perhaps we then should make a
struct state_tracker_ctx_callbacks {
};
and pass it on. That struct could then be derived from, and the co-state
tracker will tell
the pipe_screen at creation what sub-type to expect.
> The flush_frontbuffer interface will have to be rethought soon though,
> because it is not versatile enough for the WGL state tracker. Basically
> the WGL co-statetracker needs to intercept these calls so that the
> gl_framebuffer gets resized at the right timings. This means that the
> WGL needs to provide a callback whenever that flush_frontbuffer needs to
> happen, instead of having the Mesa state tracker calling
> pipe_screen::flush_frontbuffer directly. I hope to workout the details
> and provide a patch for this for review one of these days.
>
>
The DRI state tracker basically modifies the
pipe_screen::flush_frontbuffer pointer when the screen is created to
point to a state-tracker function.
That's perhaps one option. The other is for the winsys to provide a
create_screen(struct state_tracker_screen_callbacks *)
where the state tracker flush_frontbuffer hook is encapsulated in the
struct state_tracker_screen_callbacks if we decide it's indeed a state
tracker screen function and not a state tracker context function, in
which case it should be put in the
struct state_tracker_ctx_callbacks.
Again, the drm_api exposes such a create_screen function, with a
initialization argument that different state trackers can derive from.
/Thomas
> Jose
>
>
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
