Re: [Mesa3d-dev] Inter-StateTracker communication
On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz ja...@vmware.com wrote: Some things that needs to worked out about this interface is how to handle glViewport vs DRI2, since the code in glViewport needs to force a update of the buffers in DRI2 but not for other state trackers. If we can some how work around the need to force a update in a way that works on old servers that would be great, but I doubt that can be done. With the mesa/st having access to the new st_framebuffer/sm_surface, it can call validate upon glViewport. Does that suffice? I am curious about this part too. How often does DRI2GetBuffers be called in DRI2 drivers? Currently, it's basically called on every glXMake*Current or glViewport call, as there's no other reliable way to know when the buffer size might have changed. Maybe at some point there will be a DRI2 event to help with this. Something I keep pointing out though is that ideally we want to avoid calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started emitting drawing commands for a given set of DRI2 buffers, we should stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers() should only be called on a glXMake*Current or glViewport call if there's been no drawing since the last buffer swap / frontbuffer flush (and in the future maybe only if there's been no DRI2 event to signal it needs to be called). In egl_g3d, it is indirectly called in every eglSwapBuffers and flush_frontbuffer. That probably won't be enough for apps which don't render frames continuously but only on demand: buffer swap / frontbuffer flush -- DRI2GetBuffers -- window resize -- render frame: whoops, stale DRI2 buffer size -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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
Re: [Mesa3d-dev] Inter-StateTracker communication
2010/1/15 Michel Dänzer mic...@daenzer.net: On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz ja...@vmware.com wrote: Some things that needs to worked out about this interface is how to handle glViewport vs DRI2, since the code in glViewport needs to force a update of the buffers in DRI2 but not for other state trackers. If we can some how work around the need to force a update in a way that works on old servers that would be great, but I doubt that can be done. With the mesa/st having access to the new st_framebuffer/sm_surface, it can call validate upon glViewport. Does that suffice? I am curious about this part too. How often does DRI2GetBuffers be called in DRI2 drivers? Currently, it's basically called on every glXMake*Current or glViewport call, as there's no other reliable way to know when the buffer size might have changed. Maybe at some point there will be a DRI2 event to help with this. Something I keep pointing out though is that ideally we want to avoid calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started emitting drawing commands for a given set of DRI2 buffers, we should stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers() should only be called on a glXMake*Current or glViewport call if there's been no drawing since the last buffer swap / frontbuffer flush (and in the future maybe only if there's been no DRI2 event to signal it needs to be called). Thanks for the info. It seems OpenVG has no glViewport equivalent (correct me if I am wrong). Will it be an issue with current design? If an OpenGL application does not call glViewport upon window resize, is it consider an application bug? For both reasons, DRI2GetBuffers is called on every buffer swap/flush front in egl_g3d. If this is overkill, do you have any suggestion? In egl_g3d, it is indirectly called in every eglSwapBuffers and flush_frontbuffer. That probably won't be enough for apps which don't render frames continuously but only on demand: buffer swap / frontbuffer flush -- DRI2GetBuffers -- window resize -- render frame: whoops, stale DRI2 buffer size That's right. That is/was another reason I want to hook winsys-update_buffer. But with the new st_api.h, which I am working toward to, the state tracker may validate the drawable itself when glViewport is called. I think it solves the problem, right? -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
Re: [Mesa3d-dev] [PATCH] Add GALLIUM_DUMP_VS environment variable
Luca Barbieri wrote on 2009-12-26 02:06: Add GALLIUM_DUMP_VS to dump the vertex shader to the console like GALLIUM_DUMP_FS in softpipe. Commited, thanks. -- 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
Re: [Mesa3d-dev] Inter-StateTracker communication
2010/1/15 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
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.
It is for GLX, as Keith pointed out before.
Why is that? For direct and indirect rendering, under Gallium, the application
or the server is capable of creating the depth/stencil buffer from the pipe
screen.
The problem I can see here is that the depth/stencil buffer is no longer
shareable between contexts. But I am curious to know if this is a real
problem? Another question I have is, if depth/stencil should be shareable, how
about other buffers like multisample buffer? (This is a real question that has
bothered me for a while. I am eager for an answer here.)
-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
Re: [Mesa3d-dev] Inter-StateTracker communication
On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote: 2010/1/15 Michel Dänzer mic...@daenzer.net: On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz ja...@vmware.com wrote: Some things that needs to worked out about this interface is how to handle glViewport vs DRI2, since the code in glViewport needs to force a update of the buffers in DRI2 but not for other state trackers. If we can some how work around the need to force a update in a way that works on old servers that would be great, but I doubt that can be done. With the mesa/st having access to the new st_framebuffer/sm_surface, it can call validate upon glViewport. Does that suffice? I am curious about this part too. How often does DRI2GetBuffers be called in DRI2 drivers? Currently, it's basically called on every glXMake*Current or glViewport call, as there's no other reliable way to know when the buffer size might have changed. Maybe at some point there will be a DRI2 event to help with this. Something I keep pointing out though is that ideally we want to avoid calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started emitting drawing commands for a given set of DRI2 buffers, we should stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers() should only be called on a glXMake*Current or glViewport call if there's been no drawing since the last buffer swap / frontbuffer flush (and in the future maybe only if there's been no DRI2 event to signal it needs to be called). Thanks for the info. It seems OpenVG has no glViewport equivalent (correct me if I am wrong). Will it be an issue with current design? Possibly. When glViewport was chosen for this I did point out the potential problem with other APIs. If an OpenGL application does not call glViewport upon window resize, is it consider an application bug? Yes, the OpenGL viewport isn't automatically adapted on a window resize. For both reasons, DRI2GetBuffers is called on every buffer swap/flush front in egl_g3d. If this is overkill, do you have any suggestion? It's overkill as long as the window size doesn't change but at the same time possibly insufficient when it does. Unfortunately, I'm not familiar enough with EGL to make specific suggestions for a solution there. In egl_g3d, it is indirectly called in every eglSwapBuffers and flush_frontbuffer. That probably won't be enough for apps which don't render frames continuously but only on demand: buffer swap / frontbuffer flush -- DRI2GetBuffers -- window resize -- render frame: whoops, stale DRI2 buffer size That's right. That is/was another reason I want to hook winsys-update_buffer. But with the new st_api.h, which I am working toward to, the state tracker may validate the drawable itself when glViewport is called. I think it solves the problem, right? I'm not familiar with all the details, but it sounds like it might. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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
Re: [Mesa3d-dev] Inter-StateTracker communication
On Fri, 2010-01-15 at 16:43 +0800, Chia-I Wu wrote:
2010/1/15 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
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.
It is for GLX, as Keith pointed out before.
Why is that? For direct and indirect rendering, under Gallium, the
application
or the server is capable of creating the depth/stencil buffer from the pipe
screen.
The problem I can see here is that the depth/stencil buffer is no longer
shareable between contexts. But I am curious to know if this is a real
problem?
As the colour buffers are shared, I don't see why depth/stencil
shouldn't be.
Another question I have is, if depth/stencil should be shareable, how
about other buffers like multisample buffer? (This is a real question that
has
bothered me for a while. I am eager for an answer here.)
Unfortunately I don't know the answer to that, hopefully someone else
can jump in.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
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
Re: [Mesa3d-dev] Inter-StateTracker communication
2010/1/15 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-01-15 at 16:43 +0800, Chia-I Wu wrote:
2010/1/15 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
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.
It is for GLX, as Keith pointed out before.
Why is that? For direct and indirect rendering, under Gallium, the
application
or the server is capable of creating the depth/stencil buffer from the pipe
screen.
The problem I can see here is that the depth/stencil buffer is no longer
shareable between contexts. But I am curious to know if this is a real
problem?
As the colour buffers are shared, I don't see why depth/stencil
shouldn't be.
I think the all 4 of the color buffers are special in that they are potentially
visible to the user. They should be managed by the display server.
We might be able to request only the front left buffer and render to a
privately allocated back left buffer. But the only choice left upon
SwapBuffers is to copy the contents of the back buffer to the front left
buffer. Contrary, if both buffers are requested from the display server, it
might be able to swap them without copying.
This is different from the situation of depth/stencil buffer I guess. I might
overlook a use case of shareable depth/stencil buffer, and that what I want to
find out.
Another question I have is, if depth/stencil should be shareable, how
about other buffers like multisample buffer? (This is a real question that
has
bothered me for a while. I am eager for an answer here.)
Unfortunately I don't know the answer to that, hopefully someone else
can jump in.
--
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
Re: [Mesa3d-dev] Inter-StateTracker communication
On 15.01.2010 09:52, Michel Dänzer wrote: On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote: 2010/1/15 Michel Dänzer mic...@daenzer.net: On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz ja...@vmware.com wrote: Some things that needs to worked out about this interface is how to handle glViewport vs DRI2, since the code in glViewport needs to force a update of the buffers in DRI2 but not for other state trackers. If we can some how work around the need to force a update in a way that works on old servers that would be great, but I doubt that can be done. With the mesa/st having access to the new st_framebuffer/sm_surface, it can call validate upon glViewport. Does that suffice? I am curious about this part too. How often does DRI2GetBuffers be called in DRI2 drivers? Currently, it's basically called on every glXMake*Current or glViewport call, as there's no other reliable way to know when the buffer size might have changed. Maybe at some point there will be a DRI2 event to help with this. Something I keep pointing out though is that ideally we want to avoid calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started emitting drawing commands for a given set of DRI2 buffers, we should stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers() should only be called on a glXMake*Current or glViewport call if there's been no drawing since the last buffer swap / frontbuffer flush (and in the future maybe only if there's been no DRI2 event to signal it needs to be called). Thanks for the info. It seems OpenVG has no glViewport equivalent (correct me if I am wrong). Will it be an issue with current design? Possibly. When glViewport was chosen for this I did point out the potential problem with other APIs. If an OpenGL application does not call glViewport upon window resize, is it consider an application bug? Yes, the OpenGL viewport isn't automatically adapted on a window resize. So, why don't we just make it an application bug if an app doesn't call glXMakeCurrent (and corresponding functions for other APIs) on window resize ? glut and SDL already do it ... True, some apps that use glX directly will be broken, but ... that happens. GLX_UGLY_VIEWPORT_HACK_FOR_DRI2=1 gnome-shell Fine, I'll be silent now until I've familiarized with the DRI2 code and understood why it's so difficult to send a window resize event. For both reasons, DRI2GetBuffers is called on every buffer swap/flush front in egl_g3d. If this is overkill, do you have any suggestion? It's overkill as long as the window size doesn't change but at the same time possibly insufficient when it does. Unfortunately, I'm not familiar enough with EGL to make specific suggestions for a solution there. In egl_g3d, it is indirectly called in every eglSwapBuffers and flush_frontbuffer. That probably won't be enough for apps which don't render frames continuously but only on demand: buffer swap / frontbuffer flush -- DRI2GetBuffers -- window resize -- render frame: whoops, stale DRI2 buffer size That's right. That is/was another reason I want to hook winsys-update_buffer. But with the new st_api.h, which I am working toward to, the state tracker may validate the drawable itself when glViewport is called. I think it solves the problem, right? I'm not familiar with all the details, but it sounds like it might. -- 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
Re: [Mesa3d-dev] Inter-StateTracker communication
On Fri, 2010-01-15 at 11:08 +0100, Christoph Bumiller wrote: On 15.01.2010 09:52, Michel Dänzer wrote: On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote: 2010/1/15 Michel Dänzer mic...@daenzer.net: On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz ja...@vmware.com wrote: Some things that needs to worked out about this interface is how to handle glViewport vs DRI2, since the code in glViewport needs to force a update of the buffers in DRI2 but not for other state trackers. If we can some how work around the need to force a update in a way that works on old servers that would be great, but I doubt that can be done. With the mesa/st having access to the new st_framebuffer/sm_surface, it can call validate upon glViewport. Does that suffice? I am curious about this part too. How often does DRI2GetBuffers be called in DRI2 drivers? Currently, it's basically called on every glXMake*Current or glViewport call, as there's no other reliable way to know when the buffer size might have changed. Maybe at some point there will be a DRI2 event to help with this. Something I keep pointing out though is that ideally we want to avoid calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started emitting drawing commands for a given set of DRI2 buffers, we should stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers() should only be called on a glXMake*Current or glViewport call if there's been no drawing since the last buffer swap / frontbuffer flush (and in the future maybe only if there's been no DRI2 event to signal it needs to be called). Thanks for the info. It seems OpenVG has no glViewport equivalent (correct me if I am wrong). Will it be an issue with current design? Possibly. When glViewport was chosen for this I did point out the potential problem with other APIs. If an OpenGL application does not call glViewport upon window resize, is it consider an application bug? Yes, the OpenGL viewport isn't automatically adapted on a window resize. So, why don't we just make it an application bug if an app doesn't call glXMakeCurrent (and corresponding functions for other APIs) on window resize ? Because it's not required by any relevant specification. Fine, I'll be silent now until I've familiarized with the DRI2 code and understood why it's so difficult to send a window resize event. It's probably not all that difficult, just not done yet. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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
Re: [Mesa3d-dev] [RFC] instanced-arrays branch
On Wed, Jan 13, 2010 at 2:02 AM, michal mic...@vmware.com wrote:
I would like to merge this branch to master soon.
I am seeing all sorts of funny behaviors after the merge with OpenVG. The
attached patch seems to fix the problem. I am not sure if this is the right
fix...
-olv
From 6471139997b2a9afff8e0f6b4da88d71f51a2a76 Mon Sep 17 00:00:00 2001
From: Chia-I Wu olva...@gmail.com
Date: Fri, 15 Jan 2010 21:49:32 +0800
Subject: [PATCH] gallium: Fix uninitialized instance divisor and index.
---
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c |2 +-
src/gallium/auxiliary/util/u_draw_quad.c |1 +
src/gallium/auxiliary/vl/vl_compositor.c |2 ++
src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c |9 +
src/gallium/state_trackers/vega/polygon.c |1 +
5 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
index 279f4ee..23da556 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
@@ -60,7 +60,7 @@ static void fetch_pipeline_prepare( struct draw_pt_middle_end *middle,
struct draw_context *draw = fpme-draw;
struct draw_vertex_shader *vs = draw-vs.vertex_shader;
unsigned i;
- boolean instance_id_index = ~0;
+ unsigned instance_id_index = ~0;
/* Add one to num_outputs because the pipeline occasionally tags on
* an additional texcoord, eg for AA lines.
diff --git a/src/gallium/auxiliary/util/u_draw_quad.c b/src/gallium/auxiliary/util/u_draw_quad.c
index 4110485..e2e23c3 100644
--- a/src/gallium/auxiliary/util/u_draw_quad.c
+++ b/src/gallium/auxiliary/util/u_draw_quad.c
@@ -61,6 +61,7 @@ util_draw_vertex_buffer(struct pipe_context *pipe,
/* tell pipe about the vertex attributes */
for (i = 0; i num_attribs; i++) {
velements[i].src_offset = i * 4 * sizeof(float);
+ velements[i].instance_divisor = 0;
velements[i].vertex_buffer_index = 0;
velements[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
velements[i].nr_components = 4;
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c b/src/gallium/auxiliary/vl/vl_compositor.c
index fc2a1c5..954a992 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -316,6 +316,7 @@ init_buffers(struct vl_compositor *c)
pipe_buffer_unmap(c-pipe-screen, c-vertex_bufs[0].buffer);
c-vertex_elems[0].src_offset = 0;
+ c-vertex_elems[0].instance_divisor = 0;
c-vertex_elems[0].vertex_buffer_index = 0;
c-vertex_elems[0].nr_components = 2;
c-vertex_elems[0].src_format = PIPE_FORMAT_R32G32_FLOAT;
@@ -345,6 +346,7 @@ init_buffers(struct vl_compositor *c)
pipe_buffer_unmap(c-pipe-screen, c-vertex_bufs[1].buffer);
c-vertex_elems[1].src_offset = 0;
+ c-vertex_elems[0].instance_divisor = 0;
c-vertex_elems[1].vertex_buffer_index = 1;
c-vertex_elems[1].nr_components = 2;
c-vertex_elems[1].src_format = PIPE_FORMAT_R32G32_FLOAT;
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c b/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c
index caf581a..95fc486 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c
@@ -891,48 +891,57 @@ init_buffers(struct vl_mpeg12_mc_renderer *r)
/* Position element */
r-vertex_elems[0].src_offset = 0;
+ r-vertex_elems[0].instance_divisor = 0;
r-vertex_elems[0].vertex_buffer_index = 0;
r-vertex_elems[0].nr_components = 2;
r-vertex_elems[0].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* Luma, texcoord element */
r-vertex_elems[1].src_offset = sizeof(struct vertex2f);
+ r-vertex_elems[1].instance_divisor = 0;
r-vertex_elems[1].vertex_buffer_index = 0;
r-vertex_elems[1].nr_components = 2;
r-vertex_elems[1].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* Chroma Cr texcoord element */
r-vertex_elems[2].src_offset = sizeof(struct vertex2f) * 2;
+ r-vertex_elems[2].instance_divisor = 0;
r-vertex_elems[2].vertex_buffer_index = 0;
r-vertex_elems[2].nr_components = 2;
r-vertex_elems[2].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* Chroma Cb texcoord element */
r-vertex_elems[3].src_offset = sizeof(struct vertex2f) * 3;
+ r-vertex_elems[3].instance_divisor = 0;
r-vertex_elems[3].vertex_buffer_index = 0;
r-vertex_elems[3].nr_components = 2;
r-vertex_elems[3].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* First ref surface top field texcoord element */
r-vertex_elems[4].src_offset = 0;
+ r-vertex_elems[4].instance_divisor = 0;
+ r-vertex_elems[3].vertex_buffer_index = 0;
r-vertex_elems[4].vertex_buffer_index = 1;
r-vertex_elems[4].nr_components = 2;
r-vertex_elems[4].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* First ref surface bottom field texcoord element */
Re: [Mesa3d-dev] [RFC] instanced-arrays branch
On Fri, Jan 15, 2010 at 09:57:32PM +0800, Chia-I Wu wrote:
On Wed, Jan 13, 2010 at 2:02 AM, michal mic...@vmware.com wrote:
I would like to merge this branch to master soon.
I am seeing all sorts of funny behaviors after the merge with OpenVG. The
attached patch seems to fix the problem. I am not sure if this is the right
fix...
There are two typos in the changes to auxiliary/vl/. Here is the
updated patch. Sorry for the trouble.
--
Regards,
olv
From 232ae874d4bfd2b3e33bba9c7cccd47cd6d356be Mon Sep 17 00:00:00 2001
From: Chia-I Wu olva...@gmail.com
Date: Fri, 15 Jan 2010 21:49:32 +0800
Subject: [PATCH] gallium: Fix uninitialized instance divisor and index.
---
.../auxiliary/draw/draw_pt_fetch_shade_pipeline.c |2 +-
src/gallium/auxiliary/util/u_draw_quad.c |1 +
src/gallium/auxiliary/vl/vl_compositor.c |2 ++
src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c |8
src/gallium/state_trackers/vega/polygon.c |1 +
5 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
index 279f4ee..23da556 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
@@ -60,7 +60,7 @@ static void fetch_pipeline_prepare( struct draw_pt_middle_end *middle,
struct draw_context *draw = fpme-draw;
struct draw_vertex_shader *vs = draw-vs.vertex_shader;
unsigned i;
- boolean instance_id_index = ~0;
+ unsigned instance_id_index = ~0;
/* Add one to num_outputs because the pipeline occasionally tags on
* an additional texcoord, eg for AA lines.
diff --git a/src/gallium/auxiliary/util/u_draw_quad.c b/src/gallium/auxiliary/util/u_draw_quad.c
index 4110485..e2e23c3 100644
--- a/src/gallium/auxiliary/util/u_draw_quad.c
+++ b/src/gallium/auxiliary/util/u_draw_quad.c
@@ -61,6 +61,7 @@ util_draw_vertex_buffer(struct pipe_context *pipe,
/* tell pipe about the vertex attributes */
for (i = 0; i num_attribs; i++) {
velements[i].src_offset = i * 4 * sizeof(float);
+ velements[i].instance_divisor = 0;
velements[i].vertex_buffer_index = 0;
velements[i].src_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
velements[i].nr_components = 4;
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c b/src/gallium/auxiliary/vl/vl_compositor.c
index fc2a1c5..ba49ba3 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -316,6 +316,7 @@ init_buffers(struct vl_compositor *c)
pipe_buffer_unmap(c-pipe-screen, c-vertex_bufs[0].buffer);
c-vertex_elems[0].src_offset = 0;
+ c-vertex_elems[0].instance_divisor = 0;
c-vertex_elems[0].vertex_buffer_index = 0;
c-vertex_elems[0].nr_components = 2;
c-vertex_elems[0].src_format = PIPE_FORMAT_R32G32_FLOAT;
@@ -345,6 +346,7 @@ init_buffers(struct vl_compositor *c)
pipe_buffer_unmap(c-pipe-screen, c-vertex_bufs[1].buffer);
c-vertex_elems[1].src_offset = 0;
+ c-vertex_elems[1].instance_divisor = 0;
c-vertex_elems[1].vertex_buffer_index = 1;
c-vertex_elems[1].nr_components = 2;
c-vertex_elems[1].src_format = PIPE_FORMAT_R32G32_FLOAT;
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c b/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c
index caf581a..2287f9b 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c
@@ -891,48 +891,56 @@ init_buffers(struct vl_mpeg12_mc_renderer *r)
/* Position element */
r-vertex_elems[0].src_offset = 0;
+ r-vertex_elems[0].instance_divisor = 0;
r-vertex_elems[0].vertex_buffer_index = 0;
r-vertex_elems[0].nr_components = 2;
r-vertex_elems[0].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* Luma, texcoord element */
r-vertex_elems[1].src_offset = sizeof(struct vertex2f);
+ r-vertex_elems[1].instance_divisor = 0;
r-vertex_elems[1].vertex_buffer_index = 0;
r-vertex_elems[1].nr_components = 2;
r-vertex_elems[1].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* Chroma Cr texcoord element */
r-vertex_elems[2].src_offset = sizeof(struct vertex2f) * 2;
+ r-vertex_elems[2].instance_divisor = 0;
r-vertex_elems[2].vertex_buffer_index = 0;
r-vertex_elems[2].nr_components = 2;
r-vertex_elems[2].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* Chroma Cb texcoord element */
r-vertex_elems[3].src_offset = sizeof(struct vertex2f) * 3;
+ r-vertex_elems[3].instance_divisor = 0;
r-vertex_elems[3].vertex_buffer_index = 0;
r-vertex_elems[3].nr_components = 2;
r-vertex_elems[3].src_format = PIPE_FORMAT_R32G32_FLOAT;
/* First ref surface top field texcoord element */
r-vertex_elems[4].src_offset = 0;
+ r-vertex_elems[4].instance_divisor = 0;
r-vertex_elems[4].vertex_buffer_index = 1;
r-vertex_elems[4].nr_components = 2;
[Mesa3d-dev] VMWARE SVGA, gallium + xorg
Hello. I have found that in GIT there is a driver for VMWARE SVGA. So how can I use it. I have windows machine and inside VMWARE with linux. Does X.org vmware driver use Mesa3d for VMWARE SVGA? Thanks for any reply. Peter Hanzel, Senior Software Engineer Avitech s.r.o. Apollo Business Center II Prievozská 4D | 821 09 Bratislava | Slovakia T: +421 2 5564 2801 | F: +421 2 5564 2803 Avitech s.r.o. is a subsidiary of Avitech AG Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany T: +49 7541 282-0 | F: +49 7541 282-199 Court Registration: Amtsgericht Ulm | HRB 631948 Vorstand/CEO: Joachim Lennarz Chairman of the Supervisory Board: Max Ruëff VAT No.: DE223719716 www.avitech-ag.com -- 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
Re: [Mesa3d-dev] Inter-StateTracker communication
Michel Dänzer wrote: On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote: 2010/1/15 Michel Dänzer mic...@daenzer.net: On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz ja...@vmware.com wrote: Some things that needs to worked out about this interface is how to handle glViewport vs DRI2, since the code in glViewport needs to force a update of the buffers in DRI2 but not for other state trackers. If we can some how work around the need to force a update in a way that works on old servers that would be great, but I doubt that can be done. With the mesa/st having access to the new st_framebuffer/sm_surface, it can call validate upon glViewport. Does that suffice? I am curious about this part too. How often does DRI2GetBuffers be called in DRI2 drivers? Currently, it's basically called on every glXMake*Current or glViewport call, as there's no other reliable way to know when the buffer size might have changed. Maybe at some point there will be a DRI2 event to help with this. Something I keep pointing out though is that ideally we want to avoid calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started emitting drawing commands for a given set of DRI2 buffers, we should stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers() should only be called on a glXMake*Current or glViewport call if there's been no drawing since the last buffer swap / frontbuffer flush (and in the future maybe only if there's been no DRI2 event to signal it needs to be called). Thanks for the info. It seems OpenVG has no glViewport equivalent (correct me if I am wrong). Will it be an issue with current design? Possibly. When glViewport was chosen for this I did point out the potential problem with other APIs. If an OpenGL application does not call glViewport upon window resize, is it consider an application bug? Yes, the OpenGL viewport isn't automatically adapted on a window resize. But it's not an application bug. I could write a GL program that never calls glViewport and still draws something meaningful before/after window resizing. -Brian -- 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
Re: [Mesa3d-dev] Inter-StateTracker communication
Chia-I Wu wrote:
2010/1/15 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-01-15 at 12:05 +0800, Chia-I Wu wrote:
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.
It is for GLX, as Keith pointed out before.
Why is that? For direct and indirect rendering, under Gallium, the
application
or the server is capable of creating the depth/stencil buffer from the pipe
screen.
The problem I can see here is that the depth/stencil buffer is no longer
shareable between contexts. But I am curious to know if this is a real
problem?
All the buffers associated with a window should be accessible by any
client, but we've never fully supported that with DRI and I don't know
of any apps that depend upon it.
The only case where I think this has been used was in an old IRIX
utility called snoop (IIRC) that was similar to xmag but let you
inspect the back/depth/stencil buffers of any window on your screen.
It was really handy for debugging.
BTW, progs/xdemos/corender.c tests two GLX processing rendering into a
shared same window.
Another question I have is, if depth/stencil should be shareable, how
about other buffers like multisample buffer? (This is a real question that
has
bothered me for a while. I am eager for an answer here.)
Yes, I believe the GLX spec indicates that all ancillary buffers
associated with a window are to be sharable.
-Brian
--
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
Re: [Mesa3d-dev] Inter-StateTracker communication
On 15 jan 2010, at 02.48, Chia-I Wu wrote:
On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz
ja...@vmware.com wrote:
you guys are doing great work with the EGL state tracker. So I
thought it
would be a good time to open up a discussion about the way that the
API
state trackers talk to the EGL, dri and other co state trackers.
I started some work yesterday. It is based on the patch you sent
earlier, and
I have a local branch that port egl_g3d and OpenVG to the new st_api
and is
functioning. Attached in the interface part. Note that it is still
primitive.
In the interface, ST stands for state tracker and SM stands for
state
tracker manager or surface manager (i.e. EGL). There are three
characteristics that make it different from st_public.h
* the framebuffer (or surface, or drawable) is owned by SM
* no more __GLcontextModes
* besides struct st_api, there is struct sm_api that allows state
trackers to
call into the manager
I think all three are important. They should be kept in mind while
designing
the interface. Our versions both have the first two
characteristics, and the
third is used to support GL_OES_EGL_image and VG_KHR_EGL_image.
I do not think that reusing the st_framebuffrer for a image is the
right idea, a EGL image is just a pipe_texture reference and a
descriptions of which level/face/zslize to use. Now sounds just like a
pipe_surface but it has some semantics attached to it that is not
suitable for image.
I have attached a proposed interface to be used between the
different state
trackers. I know that Chia-I and I have talked about it before and
nothing
much have changed since then. The main point of this API is to
eliminate the
last references to winsys in the gallium interface, This could be
done by
just moving update_buffer/flush_frontbuffer to pipe_screen, but
this is not
acceptable, since the pipe driver is not the one to take care of
those
things.
I think this is solved by the new st_framebuffer or sm_surface?
Exactly, I just wanted to point out that update_buffer and
flush_frontbuffer on pipe_screen will go away.
Some things that needs to worked out about this interface is how to
handle
glViewport vs DRI2, since the code in glViewport needs to force a
update of
the buffers in DRI2 but not for other state trackers. If we can
some how
work around the need to force a update in a way that works on old
servers
that would be great, but I doubt that can be done.
With the mesa/st having access to the new st_framebuffer/sm_surface,
it can
call validate upon glViewport. Does that suffice?
Yes it does, except calling validate is always a heavy wight operation
(a round trip to the X server).
I am curious about this part too. How often does DRI2GetBuffers be
called in
DRI2 drivers? In egl_g3d, it is indirectly called in every
eglSwapBuffers and
flush_frontbuffer. There is no glViewport equivalent in OpenVG, it
seems, so
egl_g3d does not rely on glViewport or the equivalents being called
to update
the buffers. Surely, update_buffers will (it is not right now)
still be
hooked, but egl_g3d don't rely on it.
DRI2GetBuffers is called every glViewport and makeCurrent.
So the glViewport problem is this. The rendering API should get a
notification that it should call into the validate function. The
problem in DRI2 is that the notification is glViewport, if we can
solve that with DRI2 events thats great! The problem is that we need
to support older X servers, at least I do.
On the topic of EGL I'm wondering if this should be exposed in
st_api.h or
in some extra api on the side of st_api.h. To check if the API
supports EGL
one could introduce some sort of ST_CAPS that the api's can
communicate
between each other. Adding something like below to the st_api struct.
/**
* Query an integer-valued capability/parameter/limit
* \param param one of ST_CAP_x
*/
int (*get_param)(struct st_api *api, int param);
And then base classing st_context in a st_egl_context, which is
guarded by a
ST_CAP_EGL or something:
struct st_egl_context
{
struct st_context base;
int egl_func1(params);
...
};
Currently there is not a struct that represents the co state
tracker in this
interface, mostly because there has been no need (other then the
flush/validate functions on the framebuffer) to call into the co
state
tracker. Maybe if exposing caps back to the rendering api we can
solve the
glViewport issue by having ST_CAP_GL_VIEWPORT_ALWAYS_VALIDATE cap,
a bit
hacky yes. But I don't think any backwards compatible solution to
that
problem would be nice.
There is a need for state tracker to ask co state tracker to return
the
underlying pipe texture of an EGLImage.
See above.
I think get_param might be a good idea. In EGL, user can ask what
is the
render
Re: [Mesa3d-dev] [RFC] instanced-arrays branch
Chia-I Wu wrote on 2010-01-15 15:09: On Fri, Jan 15, 2010 at 09:57:32PM +0800, Chia-I Wu wrote: On Wed, Jan 13, 2010 at 2:02 AM, michal mic...@vmware.com wrote: I would like to merge this branch to master soon. I am seeing all sorts of funny behaviors after the merge with OpenVG. The attached patch seems to fix the problem. I am not sure if this is the right fix... There are two typos in the changes to auxiliary/vl/. Here is the updated patch. Sorry for the trouble. The patch does not apply. /c/src/mesa (master) $ git am 0001-gallium-Fix-uninitialized-instance-divisor-and-index-v2.patch Applying: gallium: Fix uninitialized instance divisor and index. c:/src/mesa/.git/rebase-apply/patch:18: trailing whitespace. unsigned instance_id_index = ~0; c:/src/mesa/.git/rebase-apply/patch:30: trailing whitespace. velements[i].instance_divisor = 0; c:/src/mesa/.git/rebase-apply/patch:42: trailing whitespace. c-vertex_elems[0].instance_divisor = 0; c:/src/mesa/.git/rebase-apply/patch:50: trailing whitespace. c-vertex_elems[1].instance_divisor = 0; c:/src/mesa/.git/rebase-apply/patch:62: trailing whitespace. r-vertex_elems[0].instance_divisor = 0; error: patch failed: src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c:6 0 error: src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c: patch does not apply error: patch failed: src/gallium/auxiliary/util/u_draw_quad.c:61 error: src/gallium/auxiliary/util/u_draw_quad.c: patch does not apply error: patch failed: src/gallium/auxiliary/vl/vl_compositor.c:316 error: src/gallium/auxiliary/vl/vl_compositor.c: patch does not apply error: patch failed: src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c:891 error: src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c: patch does not apply error: patch failed: src/gallium/state_trackers/vega/polygon.c:293 error: src/gallium/state_trackers/vega/polygon.c: patch does not apply Patch failed at 0001 gallium: Fix uninitialized instance divisor and index. When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. I think I will try to manually patch it later. Thanks! -- 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
Re: [Mesa3d-dev] Inter-StateTracker communication
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
Re: [Mesa3d-dev] Inter-StateTracker communication
Jakob Bornecrantz wrote: Hi Chia-I and Luca you guys are doing great work with the EGL state tracker. So I thought it would be a good time to open up a discussion about the way that the API state trackers talk to the EGL, dri and other co state trackers. I have attached a proposed interface to be used between the different state trackers. I know that Chia-I and I have talked about it before and nothing much have changed since then. The main point of this API is to eliminate the last references to winsys in the gallium interface, This could be done by just moving update_buffer/ flush_frontbuffer to pipe_screen, but this is not acceptable, since the pipe driver is not the one to take care of those things. Some things that needs to worked out about this interface is how to handle glViewport vs DRI2, since the code in glViewport needs to force a update of the buffers in DRI2 but not for other state trackers. If we can some how work around the need to force a update in a way that works on old servers that would be great, but I doubt that can be done. Don't we also ideally need to catch glReadBuffer / glDrawBuffer calls and forward them to the DRI state tracker to know whether to request a frontbuffer or not in double-buffered mode? /Thomas -- 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
Re: [Mesa3d-dev] [RFC] instanced-arrays branch
On Fri, Jan 15, 2010 at 07:22:52PM +0100, michal wrote: I think I will try to manually patch it later. Thanks! The first line of the patch is somehow garbled. But I am not sure if that is a good fix, so please go ahead. -- Regards, 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
