On 15 jan 2010, at 04.05, Chia-I Wu wrote:
> Hi,
>
> A separate mail for comments to st_api.h.
>
>> struct st_visual
>> {
>> enum pipe_format color_format;
>> enum pipe_format stencil_format;
>> enum pipe_format depth_format;
>> enum pipe_format accum_format;
>>
>> boolean double_buffer;
>> };
> As the st_context is able to validate the st_framebuffer itself, I am
> considering splitting the struct into
>
> struct st_context_config {
> /* does the user want to render to the back buffers? */
> boolean double_buffer;
> /* does the user want to render to the right buffers? */
> boolean stereo;
> /* does the user want a depth/stencil buffer? */
> boolean have_depth_stencil;
> };
>
> That is, the context config describes the desire of the user. It is
> passed to
> create_context. The contents are derived from GLX_DOUBLEBUFFER,
> GLX_STEREO,
> GLX_DEPTH_SIZE, and etc. They express the desireness of the users.
> For
> example, the context can always create a depth/stencil buffer from
> the pipe
> screen, but does the user want it to?
>
> struct st_framebuffer_config {
> /* the color format of the validated textures */
> enum pipe_format color_format;
> /* the desired format for depth/stencil buffer */
> enum pipe_format depth_stencil_format;
> /* does the user want to render to front or back buffer */
> boolean render_to_front;
> };
>
> The framebuffer config describes the properties of the fb and the
> desire of the
> user. The contents are derived from the display server,
> GLX_DEPTH_SIZE, and
> EGL_RENDER_BUFFER.
I don't think that splitting st_visual is a good idea. The framebuffer
config needs to be able to tell the renderer if it has stereo, double,
depth_stencil in order for it to validate at make_current time.
Without having to call to validate with all the attachments and
therefore force the manager to create all the textures.
>
>> enum st_framebuffer_attachment {
>> ST_SURFACE_FRONT_LEFT,
>> ST_SURFACE_BACK_LEFT,
>> ST_SURFACE_FRONT_RIGHT,
>> ST_SURFACE_BACK_RIGHT,
>> ST_SURFACE_DEPTH_STENCIL,
>> };
> In my version, there is no depth/stencil attachment. It is created
> by the
> state tracker from the pipe screen.
>
> The idea is, the display server provides only those potentially
> visible to the
> users. The depth/stencil buffer is an artifact. I am not sure if
> this is
> correct, but I would like to find out if depth/stencil is really
> needed to be
> allocated by the display server.
As said in later mails, depth stencil is needed for glx. One idea
would be to have the st manager return a NULL texture but still
succeed the call should it want the rendering st to create them itself.
>
>> struct st_context
>> {
>> ............................
>> ............................
>>
>> int (*bind_texture)(struct st_context *ctx,
>> struct pipe_texture *tex,
>> enum st_bind_type target, int level,
>> enum pipe_format format);
>> int (*unbind_texture)(struct st_context *ctx,
>> struct pipe_texture *tex,
>> enum st_bind_type target, int level);
> I think this can be replaced by a single "teximage". The arguments
> will be
> very similar to glTexImage* and so do the semantics.
Hmm okay, if that works for all the users of bind_texture/
unbind_texture that is fine with me.
>
>> struct st_api
>> {
>> boolean (*make_current)(struct st_api *api,
>> struct st_context *st,
>> struct st_framebuffer *draw,
>> struct st_framebuffer *read);
> I would like to see st_api->make_current take only the context to be
> made
> current. It means, all glFooBar calls will take the current context
> as an
> implicit argument. And add st_context->bind_framebuffers to bind
> the draw/read
> framebuffers.
Is there any reason for this other then saving a single TLS lookup
plus pointer comparison in the rendering API make_current? Seem
totally useless otherwise.
Cheers Jakob.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
