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.
> 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.
> 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.
> 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.
-olv
------------------------------------------------------------------------------
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
