Re: [Mesa-dev] [RFC PATCH 1/6] st_api: Remove st_module
2010/4/25 Kristian Høgsberg :
> On Sat, Apr 24, 2010 at 10:25 AM, Jakob Bornecrantz
>> -PUBLIC const struct st_module st_module_OpenGL_ES1 = {
>> - .api = ST_API_OPENGL_ES1,
>> - .create_api = st_manager_create_api
>> -};
>> +PUBLIC struct st_api *
>> +st_api_create_OpenGL_ES1()
>> +{
>> + return st_gl_api_create();
> Can we make st_gl_api_create() take an enum (like ST_API_OPENGL_ES1)
> to indicate which GL API we want to create? I have a patch series on
> the way to make core mesa multi-API aware and mesa_create_context()
> will take a similar enum from mtypes.h. If we add that argument to
> st_gl_api_create(), one gallium GL state tracker will be able to
> implement the three API in one driver.
This sounds good to me. But we need a way to know which GL APIs are
supported, in case we have an OpenGL-only or ES2-only core mesa,
without really creating the context. So that we can advertise them in
EGLConfigs. It also implies that st/egl can no longer use the
existence of certain symbols to decide which APIs are available.
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 0/6] Refactor st_api and st/dri
Hi Jakob, On Sat, Apr 24, 2010 at 10:25 PM, Jakob Bornecrantz wrote: > This Patch series does some minor refactoring in the st_api interface > and some major one to st/dri. > The first patch drops the st_module struct from st_api. This is because it > was overlapping the st_api struct. Both represent the API. It also drops some > extra symbols and instead just exposes a single st_api_create_* function to > get the st_api struct from the state tracker. > The following five patches refactor st/dri and removes some defines in favour > of hooks on dri_screen. And instead of allocating a separate struct for > st_manager and st_framebuffer makes them a base for dri_screen and > dri_drawable. And finally moves the code from dri_st_api.c into dri_screen.c > and dri_drawable.c. st_manager/st_framebuffer is intended to be inherited by the display/drawable of a co state tracker, if possible. This, and other changes look good to me. One thing I failed to do or investigate is that the callbacks of a st_manager/st_framebuffer are supposed to be thread-safe. It was planned that, while there is not much in dri_st_api.c, we can do the proper locking there before calling into the counterpart in dri/dri2/drisw. Do you think a lock will ever be required? If it is, we may put some comments to the callbacks as a reminder. -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 1/6] st_api: Remove st_module
2010/4/25 Chia-I Wu :
> 2010/4/25 Kristian Høgsberg :
>> On Sat, Apr 24, 2010 at 10:25 AM, Jakob Bornecrantz
>>> -PUBLIC const struct st_module st_module_OpenGL_ES1 = {
>>> - .api = ST_API_OPENGL_ES1,
>>> - .create_api = st_manager_create_api
>>> -};
>>> +PUBLIC struct st_api *
>>> +st_api_create_OpenGL_ES1()
>>> +{
>>> + return st_gl_api_create();
>> Can we make st_gl_api_create() take an enum (like ST_API_OPENGL_ES1)
>> to indicate which GL API we want to create? I have a patch series on
>> the way to make core mesa multi-API aware and mesa_create_context()
>> will take a similar enum from mtypes.h. If we add that argument to
>> st_gl_api_create(), one gallium GL state tracker will be able to
>> implement the three API in one driver.
> This sounds good to me. But we need a way to know which GL APIs are
> supported, in case we have an OpenGL-only or ES2-only core mesa,
> without really creating the context. So that we can advertise them in
> EGLConfigs. It also implies that st/egl can no longer use the
> existence of certain symbols to decide which APIs are available.
Yes, I'll need the same thing in the DRI interface. A way to query
the bitmask of supported APIs before creating a context.
Btw, the patch series is over here:
http://cgit.freedesktop.org/~krh/mesa/log/?h=gles2
It's up to 19 patches, and that just moving the GLES stuff into
src/main. I just need to move the drawtex functionality into mesa and
that should be all done, then I need to add the DRI driver interface
to create a context for a given API and add support to EGL/DRI2.
Kristian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] RFC: Remove internal flushes from Mesa state tracker
Now that transfers are context operations it is the driver's
responsibility to ensure that transfers happen in order with all other
context operations, so flushes and finishes inside Mesa should be no
longer necessary. The attached patch implements that.
This should proportionate significant improvements for hardware drivers
which are able to stream transfers in the command buffers.
Nevertheless, drivers must keep their part of the bargain, and I think
that's not the case yet.
You can use the softpipe/llvmpipe_flush_resource() as reference
implementation of the worst case scenario, where the driver is not able
to streamline transfers. But the expectation is that driver
implementators will want to avoid flushing as much as possible.
Jose
diff --git a/src/mesa/state_tracker/st_atom_constbuf.c b/src/mesa/state_tracker/st_atom_constbuf.c
index a8f2b87..2843910 100644
--- a/src/mesa/state_tracker/st_atom_constbuf.c
+++ b/src/mesa/state_tracker/st_atom_constbuf.c
@@ -44,7 +44,6 @@
#include "st_atom.h"
#include "st_atom_constbuf.h"
#include "st_program.h"
-#include "st_inlines.h"
/**
@@ -84,7 +83,7 @@ void st_upload_constants( struct st_context *st,
}
/* load Mesa constants into the constant buffer */
- st_no_flush_pipe_buffer_write(st, *cbuf,
+ pipe_buffer_write(st->pipe, *cbuf,
0, paramBytes,
params->ParameterValues);
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index 29c4d09..14865e6 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -44,10 +44,10 @@
#include "st_context.h"
#include "st_format.h"
#include "st_texture.h"
-#include "st_inlines.h"
#include "pipe/p_screen.h"
#include "pipe/p_context.h"
+#include "util/u_inlines.h"
#include "util/u_pack_color.h"
@@ -149,7 +149,7 @@ load_color_map_texture(GLcontext *ctx, struct pipe_resource *pt)
uint *dest;
uint i, j;
- transfer = st_cond_flush_get_tex_transfer(st_context(ctx),
+ transfer = pipe_get_transfer(st_context(ctx)->pipe,
pt, 0, 0, 0, PIPE_TRANSFER_WRITE,
0, 0, texSize, texSize);
dest = (uint *) pipe_transfer_map(pipe, transfer);
diff --git a/src/mesa/state_tracker/st_cb_accum.c b/src/mesa/state_tracker/st_cb_accum.c
index 0101837..ded0ba9 100644
--- a/src/mesa/state_tracker/st_cb_accum.c
+++ b/src/mesa/state_tracker/st_cb_accum.c
@@ -39,7 +39,6 @@
#include "st_cb_accum.h"
#include "st_cb_fbo.h"
#include "st_texture.h"
-#include "st_inlines.h"
#include "pipe/p_context.h"
#include "pipe/p_defines.h"
#include "util/u_inlines.h"
@@ -136,7 +135,7 @@ accum_accum(struct st_context *st, GLfloat value,
if (ST_DEBUG & DEBUG_FALLBACK)
debug_printf("%s: fallback processing\n", __FUNCTION__);
- color_trans = st_cond_flush_get_tex_transfer(st,
+ color_trans = pipe_get_transfer(st->pipe,
color_strb->texture,
0, 0, 0,
PIPE_TRANSFER_READ, xpos, ypos,
@@ -185,7 +184,7 @@ accum_load(struct st_context *st, GLfloat value,
if (ST_DEBUG & DEBUG_FALLBACK)
debug_printf("%s: fallback processing\n", __FUNCTION__);
- color_trans = st_cond_flush_get_tex_transfer(st, color_strb->texture,
+ color_trans = pipe_get_transfer(st->pipe, color_strb->texture,
0, 0, 0,
PIPE_TRANSFER_READ, xpos, ypos,
width, height);
@@ -241,7 +240,7 @@ accum_return(GLcontext *ctx, GLfloat value,
else
usage = PIPE_TRANSFER_WRITE;
- color_trans = st_cond_flush_get_tex_transfer(st_context(ctx),
+ color_trans = pipe_get_transfer(st_context(ctx)->pipe,
color_strb->texture, 0, 0, 0,
usage,
xpos, ypos,
@@ -301,9 +300,6 @@ st_Accum(GLcontext *ctx, GLenum op, GLfloat value)
if(!acc_strb->data)
return;
- /* make sure color bufs aren't cached */
- st_flush( st, PIPE_FLUSH_RENDER_CACHE, NULL );
-
switch (op) {
case GL_ADD:
if (value != 0.0F) {
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c b/src/mesa/state_tracker/st_cb_bitmap.c
index 797c0ba..6aefa7b 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -43,7 +43,6 @@
#include "st_program.h"
#include "st_cb_bitmap.h"
#include "st_texture.h"
-#include "st_inlines.h"
#include "pipe/p_context.h"
#include "pipe/p_defines.h"
@@ -282,7 +281,7 @@ make_bitmap_texture(GLcontext *ctx, GLsizei width, GLsizei height,
return NULL;
}
- transfer = st_no_flush_get_tex_transfer(st, pt, 0, 0, 0,
+ transfer = pipe_get_transfer(st->pipe, pt, 0, 0, 0,
PIPE_TRANSFER_WRITE,
0, 0, width, height);
@@ -382,7 +381,7 @@ setup_bitmap_vertex_data(struct st_context *st,
}
/* put vertex data into vbuf */
- st_no_flush_pipe_buffer_write_nooverlap(st,
+ pipe_buffer_write_nooverlap(st->pipe,
st->bitmap.vbuf,
st->bitmap.vbuf_s
[Mesa-dev] [Bug 19430] Humus DepthOfField2 demo: No matching FBConfig
https://bugs.freedesktop.org/show_bug.cgi?id=19430 --- Comment #5 from Sven Arvidsson 2010-04-25 10:40:26 PDT --- Created an attachment (id=35279) --> (https://bugs.freedesktop.org/attachment.cgi?id=35279) backtrace With the Xserver patched for pbuffer support, I can run the Windows version of the demo. The Linux version no longer complains about missing fbconfigs but segfaults instead. This is the line which is causing the problem: glXBindTexImageATI(display, (GLXPbuffer) textures[textureID].renderTargetData[0], GLX_FRONT_LEFT_ATI); Full backtrace is attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL on linux
On Thu, 2010-04-22 at 19:48 +0200, Aljoša Mohorović wrote: > i've tried to enable webgl in chrome/webkit and firefox dev builds on > intel and ati cards but got the same results. > since i'm running opengl apps on both cards i guess it is something > related with webgl implementation in browsers. > i've posted this because i don't want linux/xorg to have the worst > support for webgl but if both chrome and firefox dev builds are > failing (i've tested this on 2 different cards and did some research) > most system with xorg will have no support for webgl. Google Chrome also uses pbuffers (and framebuffer objects) for their implementation. With an Xserver patched for pbuffer support, WebGL in Chrome is working fine, similar with Firefox with Kristian's patch [1] applied. So that's my experience with WebGL using the i965 driver. 1. https://bugzilla.mozilla.org/show_bug.cgi?id=558867 -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
