[Mesa-dev] [Bug 39393] New: [PNV] X Error of failed request: BadMatch (invalid parameter attributes) when run jkrahantest
https://bugs.freedesktop.org/show_bug.cgi?id=39393 Summary: [PNV] X Error of failed request: BadMatch (invalid parameter attributes) when run jkrahantest Product: Mesa Version: unspecified Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Demos AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: bo.c...@intel.com System Environment: -- Libdrm(master)2.4.26-1-g8d055890d90c3d92647e3d8b98d32630ef87c2c8 Mesa: (7.11)7d8a04643f068fc88a1f1e119820c3c33cf6098e Xserver: (server-1.10-branch)xorg-server-1.10.3-3- g64ea1ac3208155e8caf740f0b6623997dca0bf69 Xf86_video_intel:(master)2.15.0-203-g212fa9868767637e8f430485eeb522c99e63fd16 Cairo:(master)3a293657133145e1ecc4e7c047069cb465f6b4ef Libva:(master)270299fc541c9f78efc43f1e87f6b7efd5373ec1 Kernel:(drm-intel-fixes) 435793dfb8aec7b2e19f72d5bce8a22fd0b57839 Bug detailed description: - There are some errors when run jkrahantest after startx,and the error messages as follow: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 152 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 48 Current serial number in output stream: 49 Reproduce steps: 1. xinit & 2. gnome-session 3. run src/tests/jkrahantest -- 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
[Mesa-dev] [PATCH] i965: fix timer query on gen6+
on gen6+, PIPE_CONTROL reported time stamp are 64 bits
value (high 32 bits MBZ on snb), toggles every 80 ns.
Signed-off-by: Zou Nan hai
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index b41d05d..2e04fc2 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -47,7 +47,7 @@
/** Waits on the query object's BO and totals the results for this query */
static void
-brw_queryobj_get_results(struct brw_query_object *query)
+brw_queryobj_get_results(struct brw_query_object *query, int gen)
{
int i;
uint64_t *results;
@@ -58,7 +58,10 @@ brw_queryobj_get_results(struct brw_query_object *query)
drm_intel_bo_map(query->bo, GL_FALSE);
results = query->bo->virtual;
if (query->Base.Target == GL_TIME_ELAPSED_EXT) {
- query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >> 32));
+ if (gen >= 6)
+ query->Base.Result += 80 * (results[1] - results[0]);
+ else
+ query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >>
32));
} else {
/* Map and count the pixels from the current query BO */
for (i = query->first_index; i <= query->last_index; i++) {
@@ -200,17 +203,21 @@ brw_end_query(struct gl_context *ctx, struct
gl_query_object *q)
static void brw_wait_query(struct gl_context *ctx, struct gl_query_object *q)
{
struct brw_query_object *query = (struct brw_query_object *)q;
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = intel_context(ctx);
- brw_queryobj_get_results(query);
+ brw_queryobj_get_results(query, intel->gen);
query->Base.Ready = GL_TRUE;
}
static void brw_check_query(struct gl_context *ctx, struct gl_query_object *q)
{
struct brw_query_object *query = (struct brw_query_object *)q;
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = intel_context(ctx);
if (query->bo == NULL || !drm_intel_bo_busy(query->bo)) {
- brw_queryobj_get_results(query);
+ brw_queryobj_get_results(query, intel->gen);
query->Base.Ready = GL_TRUE;
}
}
@@ -295,7 +302,7 @@ brw_emit_query_begin(struct brw_context *brw)
if (query->bo != brw->query.bo) {
if (query->bo != NULL)
-brw_queryobj_get_results(query);
+brw_queryobj_get_results(query, intel->gen);
drm_intel_bo_reference(brw->query.bo);
query->bo = brw->query.bo;
query->first_index = brw->query.index;
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] u_vbuf_mgr: restore buffer offsets
From: Chia-I Wu
u_vbuf_upload_buffers modifies the buffer offsets. If they are not
restored, and any of the vertex formats is not supported natively, the
next u_vbuf_mgr_draw_begin call will translate the vertex buffers with
incorrect buffer offsets.
---
src/gallium/auxiliary/util/u_vbuf_mgr.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_vbuf_mgr.c
b/src/gallium/auxiliary/util/u_vbuf_mgr.c
index 374fc33..47e7027 100644
--- a/src/gallium/auxiliary/util/u_vbuf_mgr.c
+++ b/src/gallium/auxiliary/util/u_vbuf_mgr.c
@@ -79,6 +79,8 @@ struct u_vbuf_mgr_priv {
void *saved_ve, *fallback_ve;
boolean ve_binding_lock;
+ unsigned saved_buffer_offset[PIPE_MAX_ATTRIBS];
+
boolean any_user_vbs;
boolean incompatible_vb_layout;
};
@@ -488,6 +490,7 @@ void u_vbuf_mgr_set_vertex_buffers(struct u_vbuf_mgr *mgrb,
pipe_resource_reference(&mgr->b.vertex_buffer[i].buffer, vb->buffer);
pipe_resource_reference(&mgr->b.real_vertex_buffer[i], NULL);
+ mgr->saved_buffer_offset[i] = vb->buffer_offset;
if (!vb->buffer) {
continue;
@@ -647,6 +650,17 @@ u_vbuf_mgr_draw_begin(struct u_vbuf_mgr *mgrb,
void u_vbuf_mgr_draw_end(struct u_vbuf_mgr *mgrb)
{
struct u_vbuf_mgr_priv *mgr = (struct u_vbuf_mgr_priv*)mgrb;
+ unsigned i;
+
+ /* buffer offsets were modified in u_vbuf_upload_buffers */
+ if (mgr->any_user_vbs) {
+ for (i = 0; i < mgr->ve->count; i++) {
+ unsigned index = mgr->ve->ve[i].vertex_buffer_index;
+ struct pipe_vertex_buffer *vb = &mgr->b.vertex_buffer[index];
+
+ vb->buffer_offset = mgr->saved_buffer_offset[index];
+ }
+ }
if (mgr->fallback_ve) {
u_vbuf_translate_end(mgr);
--
1.7.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 2
On Wed, Jul 20, 2011 at 1:08 AM, Sebastian H. wrote: > Hello list > >> Mesa 7.11-rc2 has been released. This is a release candidate for the >> 7.11 development release. > > I've tried to compile this one > >> 996aea3cca40bb34c0a9027411924879 MesaGLUT-7.11-rc2.tar.bz2 > > After unpacking > > ./configure --prefix=/opt/mesa PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig > LC_ALL=C make -j8 > > Make fails here > > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/opt/mesa/include -I/opt/mesa/include/libdrm -DFEATURE_GL=1 > -I/opt/mesa/include -I/opt/mesa/include/libdrm -I/usr/include/libdrm > -I/usr/include/nouveau -g -O2 -Wall -Wmissing-prototypes -std=c99 > -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE > -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS > -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0206 > -fvisibility=hidden nouveau_bo_state.c -o nouveau_bo_state.o > In file included from nouveau_fbo.c:27: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > In file included from nouveau_state.c:27: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > In file included from nouveau_state.c:30: > nouveau_util.h: In function 'OUT_RINGb': > nouveau_util.h:169: warning: implicit declaration of function 'OUT_RING' > nouveau_util.h: In function 'OUT_RINGm': > nouveau_util.h:179: warning: implicit declaration of function 'OUT_RINGf' > In file included from nouveau_screen.c:27: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > make[6]: *** [nouveau_fbo.o] Error 1 > make[6]: *** Waiting for unfinished jobs > In file included from nouveau_context.c:27: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > make[6]: *** [nouveau_state.o] Error 1 > make[6]: *** [nouveau_screen.o] Error 1 > In file included from nouveau_driver.c:29: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > In file included from nouveau_span.c:27: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > In file included from nouveau_bufferobj.c:27: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > In file included from nouveau_driver.c:32: > nouveau_util.h: In function 'OUT_RINGb': > nouveau_util.h:169: warning: implicit declaration of function 'OUT_RING' > nouveau_util.h: In function 'OUT_RINGm': > nouveau_util.h:179: warning: implicit declaration of function 'OUT_RINGf' > nouveau_driver.c: In function 'nouveau_flush': > nouveau_driver.c:62: warning: implicit declaration of function 'FIRE_RING' > make[6]: *** [nouveau_bufferobj.o] Error 1 > In file included from nouveau_bo_state.c:27: > nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory > nouveau_bo_state.c: In function 'nouveau_bo_marker_emit': > nouveau_bo_state.c:40: warning: implicit declaration of function 'MARK_RING' > nouveau_bo_state.c:46: warning: implicit declaration of function > 'nouveau_pushbuf_emit_reloc' > nouveau_bo_state.c:46: error: 'struct nouveau_channel' has no member named > 'cur' > nouveau_bo_state.c:54: error: 'struct nouveau_channel' has no member named > 'cur' > nouveau_bo_state.c:57: error: 'struct nouveau_channel' has no member named > 'cur' > nouveau_bo_state.c:65: warning: implicit declaration of function 'MARK_UNDO' > make[6]: *** [nouveau_driver.o] Error 1 > make[6]: *** [nouveau_bo_state.o] Error 1 > make[6]: *** [nouveau_span.o] Error 1 > nouveau_context.c: In function 'nouveau_context_init': > nouveau_context.c:133: warning: passing argument 4 of > 'nouveau_channel_alloc' makes pointer from integer without a cast > /usr/include/nouveau/nouveau_channel.h:50: note: expected 'struct > nouveau_channel **' but argument is of type 'int' > nouveau_context.c:133: error: too many arguments to function > 'nouveau_channel_alloc' > nouveau_context.c: In function 'update_framebuffer': > nouveau_context.c:282: warning: implicit declaration of function 'FIRE_RING' > make[6]: *** [nouveau_context.o] Error 1 > make[6]: Leaving directory > `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri/nouveau' > make[5]: *** [lib] Error 2 > make[5]: Leaving directory > `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri/nouveau' > make[4]: *** [subdirs] Error 1 > make[4]: Leaving directory > `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri' > make[3]: *** [default] Error 1 > make[3]: Leaving directory > `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers' > make[2]: *** [driver_subdirs] Error 2 > make[2]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa' > make[1]: *** [subdirs] Error 1 > make[1]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src' > mak
Re: [Mesa-dev] Mesa 7.11 release candidate 2
On 07/20/2011 07:38 AM, Matt Turner wrote: On Wed, Jul 20, 2011 at 1:08 AM, Sebastian H. wrote: Hello list Mesa 7.11-rc2 has been released. This is a release candidate for the 7.11 development release. I've tried to compile this one 996aea3cca40bb34c0a9027411924879 MesaGLUT-7.11-rc2.tar.bz2 After unpacking ./configure --prefix=/opt/mesa PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig LC_ALL=C make -j8 Make fails here gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/opt/mesa/include -I/opt/mesa/include/libdrm-DFEATURE_GL=1 -I/opt/mesa/include -I/opt/mesa/include/libdrm -I/usr/include/libdrm -I/usr/include/nouveau -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0206 -fvisibility=hidden nouveau_bo_state.c -o nouveau_bo_state.o In file included from nouveau_fbo.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_state.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_state.c:30: nouveau_util.h: In function 'OUT_RINGb': nouveau_util.h:169: warning: implicit declaration of function 'OUT_RING' nouveau_util.h: In function 'OUT_RINGm': nouveau_util.h:179: warning: implicit declaration of function 'OUT_RINGf' In file included from nouveau_screen.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory make[6]: *** [nouveau_fbo.o] Error 1 make[6]: *** Waiting for unfinished jobs In file included from nouveau_context.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory make[6]: *** [nouveau_state.o] Error 1 make[6]: *** [nouveau_screen.o] Error 1 In file included from nouveau_driver.c:29: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_span.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_bufferobj.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory In file included from nouveau_driver.c:32: nouveau_util.h: In function 'OUT_RINGb': nouveau_util.h:169: warning: implicit declaration of function 'OUT_RING' nouveau_util.h: In function 'OUT_RINGm': nouveau_util.h:179: warning: implicit declaration of function 'OUT_RINGf' nouveau_driver.c: In function 'nouveau_flush': nouveau_driver.c:62: warning: implicit declaration of function 'FIRE_RING' make[6]: *** [nouveau_bufferobj.o] Error 1 In file included from nouveau_bo_state.c:27: nouveau_driver.h:49:26: error: nv04_pushbuf.h: No such file or directory nouveau_bo_state.c: In function 'nouveau_bo_marker_emit': nouveau_bo_state.c:40: warning: implicit declaration of function 'MARK_RING' nouveau_bo_state.c:46: warning: implicit declaration of function 'nouveau_pushbuf_emit_reloc' nouveau_bo_state.c:46: error: 'struct nouveau_channel' has no member named 'cur' nouveau_bo_state.c:54: error: 'struct nouveau_channel' has no member named 'cur' nouveau_bo_state.c:57: error: 'struct nouveau_channel' has no member named 'cur' nouveau_bo_state.c:65: warning: implicit declaration of function 'MARK_UNDO' make[6]: *** [nouveau_driver.o] Error 1 make[6]: *** [nouveau_bo_state.o] Error 1 make[6]: *** [nouveau_span.o] Error 1 nouveau_context.c: In function 'nouveau_context_init': nouveau_context.c:133: warning: passing argument 4 of 'nouveau_channel_alloc' makes pointer from integer without a cast /usr/include/nouveau/nouveau_channel.h:50: note: expected 'struct nouveau_channel **' but argument is of type 'int' nouveau_context.c:133: error: too many arguments to function 'nouveau_channel_alloc' nouveau_context.c: In function 'update_framebuffer': nouveau_context.c:282: warning: implicit declaration of function 'FIRE_RING' make[6]: *** [nouveau_context.o] Error 1 make[6]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri/nouveau' make[5]: *** [lib] Error 2 make[5]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri/nouveau' make[4]: *** [subdirs] Error 1 make[4]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers/dri' make[3]: *** [default] Error 1 make[3]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa/drivers' make[2]: *** [driver_subdirs] Error 2 make[2]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/sebastian/source/Mesa-7.11-rc2/src' make: *** [default] Error 1 nv04_pushbuf.h is included in libdrm/nouveau. It doesn't look like you have it installed. I've run into this too, act
Re: [Mesa-dev] [PATCH] st/mesa: st_copy_texsubimage: clip source size to rb size
On 07/18/2011 09:19 PM, Brian Paul wrote:
On 07/18/2011 09:29 AM, Vadim Girlin wrote:
On Mon, 2011-07-18 at 08:34 -0600, Brian Paul wrote:
On Mon, Jul 18, 2011 at 8:11 AM, Vadim
Girlin wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39286
---
src/mesa/state_tracker/st_cb_texture.c | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 6907cfc..63cd142 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1490,6 +1490,14 @@ st_copy_texsubimage(struct gl_context *ctx,
destY = 0;
}
+ if (srcX + width> strb->Base.Width) {
+ width = strb->Base.Width - srcX;
+ }
+
+ if (srcY + height> strb->Base.Height) {
+ height = strb->Base.Height - srcY;
+ }
+
if (width< 0 || height< 0)
return;
Clipping for glCopyTexSubImage() should be done by
_mesa_clip_copytexsubimage() (in image.c, called from teximage.c).
Maybe you could do a bit of debugging to see why that's not doing the
job.
Yes, I have some doubts too, especially now when I've seen the comment
before the st_copy_texsubimage definition, which explicitly states the
region should be clipped already. AFAICS _mesa_clip_copytexsubimage is
called only from copytexsubimage, but st_copy_texsubimage is called
from
copyteximage (without sub) too, that's why no clipping occurs. I'm not
sure now where and how is better to fix it then, because my
knowledge of
this code is still not very good. On the other hand,
st_copy_texsubimage
already contains some clipping code, that's why I've added the
checks in
this function. How should I fix this correctly?
Here's a patch to try.
Basically, it reimplements glCopyTexImage() like a sequence of
glTexImage() and glCopyTexSubImage() calls (and does the clipping that
was missing). I was planning on doing this as a follow-on to the
map-texture-image-v4 work.
With this change, we can remove the ctx->Driver.CopyTexImage1D/2D()
hooks and the corresponding code in all the drivers.
I've made a branch that does this: remove-copyteximage-hook
The intel and radeon drivers and the gallium state tracker were
basically doing what core Mesa is now doing.
I think it's a pretty safe change but it wouldn't hurt if a few people
tested the branch. I'll merge it to master in a day or two.
It always feels good to remove a few hundred lines of code.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38869] Cannot create a valid pBuffer with height and/or width of zero
https://bugs.freedesktop.org/show_bug.cgi?id=38869 --- Comment #1 from Brian Paul 2011-07-20 07:25:36 PDT --- "Both the EGL and GLX specifications allow pbuffers to be created with a height and/or width of zero (and these are the default values)." [...] "Other implementations throw a BAD_VALUE error in this case although this is not part of either specification." I'm not clear on what you're saying. According to the GLX spec, it looks like a size 0 x 0 pbuffer is legal. But are you saying other implementations throw BadValue if you try that? In Mesa, have you tried removing the width==0 || height==0 check? If so, what happens when you create a 0x0 pbuffer? Also, off-hand, I don't know of a way to directly generate an X error with Xlib calls. Remember, the fake GLX layer we're talking about here has no internal hooks into X so we can't do everything that the real GLX library does. I suppose we could set up an unrelated protocol request that purposely has bad arguments to generate the error. If you need this, could you try to implement it? -- 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] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
On 07/19/2011 05:59 PM, Paul Berry wrote: On 19 July 2011 13:15, Ian Romanick wrote: src/egl/main/eglcompiler.h src/gallium/include/pipe/p_compiler.h src/mapi/mapi/u_compiler.h src/mesa/main/compiler.h None of those headers should ever cross paths. The only one of those that anything under src/mesa/main or src/glsl should *ever* hit is src/mesa/main/compiler.h. Where did the colliding definition come from? The colliding definition was in src/mapi/mapi/u_compiler.h. At least one of the conflicting paths is: glsl/link_functions.cpp includes mesa/main/core.h, which includes mesa/main/mtypes.h, which includes mapi/glapi/glapi.h, which includes mapi/glapi/glthread.h, which includes mapi/mapi/u_thread.h, which includes mapi/mapi/u_compiler.h mesa/main/core.h also includes mesa/main/compiler.h I don't know whether there are other conflicting paths. This conflict doesn't lead to compile errors right now (presumably because mesa/main/compiler.h gets included first, and the definition of INLINE in mapi/mapi/u_compiler.h only happens if INLINE is not already defined). However, in patch 2/4 of this patch series, I had to make glsl/glsl_parser_extras.h include main/mtypes.h (so that I could add a function to glsl_parser_extras.h that referred to gl_api). That must have changed the order in which the files get included so that mapi/mapi/u_compiler.h got included first. Thanks for the explanation. I'm OK with your original patch. I don't think any of us has time for more elaborate refactoring right now. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 2
>>> Mesa 7.11-rc2 has been released. This is a release candidate for the >>> 7.11 development release. >> >> I've tried to compile this one >> >>> 996aea3cca40bb34c0a9027411924879 MesaGLUT-7.11-rc2.tar.bz2 >> >> After unpacking >> >> ./configure --prefix=/opt/mesa PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig >> LC_ALL=C make -j8 >> >> Make fails here > nv04_pushbuf.h is included in libdrm/nouveau. It doesn't look like you > have it installed. Indeed it isn't installed anywhere in /opt (also not in /usr). Btw. the latest git mesa main compiles without it beeing there. Alright, on the same system in ~/source/libdrm-2.4.26/ ./configure --prefix=/opt/mesa \ LDFLAGS=-L/opt/mesa/lib \ PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig finishes with ... libdrm 2.4.26 will be compiled with: libkms yes Intel API yes vmwgfx API no Radeon API yes Nouveau APIno ... The Noveau API doesn't get installed after the autodetection. This is a Debian/Squeeze system with a self-compiled 2.6.38 kernel and a RV570 card. Maybe something is missing or too old for Nouveau. Sebastian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38869] Cannot create a valid pBuffer with height and/or width of zero
https://bugs.freedesktop.org/show_bug.cgi?id=38869 --- Comment #2 from Ian Romanick 2011-07-20 07:42:30 PDT --- (In reply to comment #0) > Both the EGL and GLX specifications allow pbuffers to be created with a height > and/or width of zero (and these are the default values). Is there any language in the specs that specifically allow this? If there is, we should add a test case. -- 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
[Mesa-dev] [Bug 38869] Cannot create a valid pBuffer with height and/or width of zero
https://bugs.freedesktop.org/show_bug.cgi?id=38869 Ian Romanick changed: What|Removed |Added CC||i...@freedesktop.org -- 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] [PATCH 1/4] mesa: Add an ifndef guard around the definition of the INLINE macro
On 07/18/2011 11:37 AM, Paul Berry wrote: > Several headers redundantly define the INLINE macro. Adding this > guard prevents the compiler from complaining about macro redefinition. > --- > src/mesa/main/compiler.h | 42 ++ > 1 files changed, 22 insertions(+), 20 deletions(-) Ifdef-guarding such a commonly defined macro is a good idea. Reviewed-by: Chad Versace -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38869] Cannot create a valid pBuffer with height and/or width of zero
https://bugs.freedesktop.org/show_bug.cgi?id=38869 --- Comment #3 from Brian Paul 2011-07-20 07:52:24 PDT --- (In reply to comment #2) > (In reply to comment #0) > > Both the EGL and GLX specifications allow pbuffers to be created with a > > height > > and/or width of zero (and these are the default values). > > Is there any language in the specs that specifically allow this? If there is, > we should add a test case. The spec says the default values for the width/height attribs are zero. That's all I found after a quick skim. -- 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] [PATCH 2/4] glsl: Move initialize_context() to glsl_parser_extras.cpp so it can be re-used.
Comments below.
On 07/18/2011 11:37 AM, Paul Berry wrote:
> This function is used by main.cpp to initialize a context to a default
> configuration for use in compiling builtins. Moved the bulk of it to
> glsl_parser_extras.cpp so that it can be re-used in testing.
> ---
> src/glsl/glsl_parser_extras.cpp | 33 +
> src/glsl/glsl_parser_extras.h | 11 +++
> src/glsl/main.cpp | 25 +
> 3 files changed, 45 insertions(+), 24 deletions(-)
>
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index cc78137..936dbcc 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -926,6 +926,39 @@ do_common_optimization(exec_list *ir, bool linked,
> unsigned max_unroll_iteration
> return progress;
> }
>
> +void initialize_context_to_defaults(struct gl_context *ctx, gl_api api)
> +{
> + memset(ctx, 0, sizeof(*ctx));
> +
> + ctx->API = api;
> +
> + ctx->Extensions.ARB_ES2_compatibility = GL_TRUE;
> + ctx->Extensions.ARB_draw_buffers = GL_TRUE;
> + ctx->Extensions.ARB_draw_instanced = GL_TRUE;
> + ctx->Extensions.ARB_fragment_coord_conventions = GL_TRUE;
> + ctx->Extensions.EXT_texture_array = GL_TRUE;
> + ctx->Extensions.NV_texture_rectangle = GL_TRUE;
> + ctx->Extensions.EXT_texture3D = GL_TRUE;
> +
> + ctx->Const.GLSLVersion = 120;
> +
> + /* 1.10 minimums. */
> + ctx->Const.MaxLights = 8;
There is conflict here. The GLSL vrsion is 1.20, but the comment says 1.10.
The minimum values below are identical for both versions, so I can't determine
which is correct---1.10 or 1.20.
> + ctx->Const.MaxClipPlanes = 6;
> + ctx->Const.MaxTextureUnits = 2;
> + ctx->Const.MaxTextureCoordUnits = 2;
> + ctx->Const.VertexProgram.MaxAttribs = 16;
> +
> + ctx->Const.VertexProgram.MaxUniformComponents = 512;
> + ctx->Const.MaxVarying = 8;
> + ctx->Const.MaxVertexTextureImageUnits = 0;
> + ctx->Const.MaxCombinedTextureImageUnits = 2;
> + ctx->Const.MaxTextureImageUnits = 2;
> + ctx->Const.FragmentProgram.MaxUniformComponents = 64;
> +
> + ctx->Const.MaxDrawBuffers = 2;
^^^
For GLSL 1.10 and 1.20, the minimum gl_MaxDrawBuffers is 1.
Is there a reason why you chose 2? If so, it should be
documented why you deviated from the minimum value.
> +}
> +
> extern "C" {
>
> /**
> diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
> index 2f4d3cb..3f88abd 100644
> --- a/src/glsl/glsl_parser_extras.h
> +++ b/src/glsl/glsl_parser_extras.h
> @@ -33,6 +33,7 @@
>
> #include
> #include "glsl_symbol_table.h"
> +#include "main/mtypes.h"
>
> enum _mesa_glsl_parser_targets {
> vertex_shader,
> @@ -258,6 +259,16 @@ extern bool _mesa_glsl_process_extension(const char
> *name, YYLTYPE *name_locp,
> extern const char *
> _mesa_glsl_shader_target_name(enum _mesa_glsl_parser_targets target);
>
> +/**
> + * Initialize the given gl_context structure to a reasonable set of
> + * defaults representing the minimum capabilities required by the
> + * OpenGL spec.
> + *
> + * This is used when compiling builtin functions and in testing, when
> + * we don't have a connection to an actual driver.
> + */
> +void initialize_context_to_defaults(struct gl_context *ctx, gl_api api);
> +
>
> #endif /* __cplusplus */
>
> diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
> index 7952bb1..4cfcf0c 100644
> --- a/src/glsl/main.cpp
> +++ b/src/glsl/main.cpp
> @@ -66,43 +66,20 @@ _mesa_new_shader(struct gl_context *ctx, GLuint name,
> GLenum type)
> static void
> initialize_context(struct gl_context *ctx, gl_api api)
> {
> - memset(ctx, 0, sizeof(*ctx));
> -
> - ctx->API = api;
> -
> - ctx->Extensions.ARB_ES2_compatibility = GL_TRUE;
> - ctx->Extensions.ARB_draw_buffers = GL_TRUE;
> - ctx->Extensions.ARB_draw_instanced = GL_TRUE;
> - ctx->Extensions.ARB_fragment_coord_conventions = GL_TRUE;
> - ctx->Extensions.EXT_texture_array = GL_TRUE;
> - ctx->Extensions.NV_texture_rectangle = GL_TRUE;
> - ctx->Extensions.EXT_texture3D = GL_TRUE;
> + initialize_context_to_defaults(ctx, api);
>
> /* GLSL 1.30 isn't fully supported, but we need to advertise 1.30 so that
> * the built-in functions for 1.30 can be built.
> */
> ctx->Const.GLSLVersion = 130;
>
> - /* 1.10 minimums. */
> - ctx->Const.MaxLights = 8;
> ctx->Const.MaxClipPlanes = 8;
> - ctx->Const.MaxTextureUnits = 2;
>
> /* More than the 1.10 minimum to appease parser tests taken from
> * apps that (hopefully) already checked the number of coords.
> */
> ctx->Const.MaxTextureCoordUnits = 4;
>
> - ctx->Const.VertexProgram.MaxAttribs = 16;
> - ctx->Const.VertexProgram.MaxUniformComponents = 512;
> - ctx->Const.MaxVarying = 8;
> - ctx->Const.MaxVertexTextureImageUnits = 0;
> - ctx->Const.MaxCombinedTextureImageUnits = 2;
> - ctx->Const.MaxTextureImageUnits = 2;
> - ct
Re: [Mesa-dev] [PATCH 3/4] glsl: Create a standalone executable for testing optimization passes.
On 07/19/2011 04:30 PM, Paul Berry wrote:
> On 19 July 2011 13:15, Ian Romanick wrote:
On the issue of std::stringbuf, I'm siding with Paul here. This
concise, safe function definition:
static string read_stdin_to_eof()
{
stringbuf sb;
cin.get(sb, '\0');
return sb.str();
}
is vastly more palatable than this bug-prone mess:
> static char *read_stdin_to_eof()
> {
> char buffer[4096] = "\0";
> size_t len = 0;
> char *result = (char *) malloc(1);
> while(fgets(buffer, sizeof(buffer), stdin))
> {
> size_t bytes_read = strlen(buffer);
> result = (char *) realloc(result, len + bytes_read + 1);
> memcpy(result + len, buffer, bytes_read);
> len += bytes_read;
> }
> result[len] = '\0';
> return result;
> }
--
Chad Versace
c...@chad-versace.us
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] u_vbuf_mgr: restore buffer offsets
Well spotted, thanks. Some comments below.
On Wed, Jul 20, 2011 at 3:25 PM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> u_vbuf_upload_buffers modifies the buffer offsets. If they are not
> restored, and any of the vertex formats is not supported natively, the
> next u_vbuf_mgr_draw_begin call will translate the vertex buffers with
> incorrect buffer offsets.
> ---
> src/gallium/auxiliary/util/u_vbuf_mgr.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_vbuf_mgr.c
> b/src/gallium/auxiliary/util/u_vbuf_mgr.c
> index 374fc33..47e7027 100644
> --- a/src/gallium/auxiliary/util/u_vbuf_mgr.c
> +++ b/src/gallium/auxiliary/util/u_vbuf_mgr.c
> @@ -79,6 +79,8 @@ struct u_vbuf_mgr_priv {
> void *saved_ve, *fallback_ve;
> boolean ve_binding_lock;
>
> + unsigned saved_buffer_offset[PIPE_MAX_ATTRIBS];
> +
> boolean any_user_vbs;
> boolean incompatible_vb_layout;
> };
> @@ -488,6 +490,7 @@ void u_vbuf_mgr_set_vertex_buffers(struct u_vbuf_mgr
> *mgrb,
>
> pipe_resource_reference(&mgr->b.vertex_buffer[i].buffer, vb->buffer);
> pipe_resource_reference(&mgr->b.real_vertex_buffer[i], NULL);
> + mgr->saved_buffer_offset[i] = vb->buffer_offset;
>
> if (!vb->buffer) {
> continue;
> @@ -647,6 +650,17 @@ u_vbuf_mgr_draw_begin(struct u_vbuf_mgr *mgrb,
> void u_vbuf_mgr_draw_end(struct u_vbuf_mgr *mgrb)
> {
> struct u_vbuf_mgr_priv *mgr = (struct u_vbuf_mgr_priv*)mgrb;
> + unsigned i;
> +
> + /* buffer offsets were modified in u_vbuf_upload_buffers */
> + if (mgr->any_user_vbs) {
That conditional should probably be:
if (mgr->any_user_vbs || mgr->fallback_ve)
Because the translate fallback changes the buffer offsets too.
> + for (i = 0; i < mgr->ve->count; i++) {
> + unsigned index = mgr->ve->ve[i].vertex_buffer_index;
> + struct pipe_vertex_buffer *vb = &mgr->b.vertex_buffer[index];
> +
> + vb->buffer_offset = mgr->saved_buffer_offset[index];
> + }
Why not loop over vertex buffers instead of vertex elements?
Marek
> + }
>
> if (mgr->fallback_ve) {
> u_vbuf_translate_end(mgr);
> --
> 1.7.5.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 2
On Wed, Jul 20, 2011 at 4:39 PM, Sebastian H. wrote: Mesa 7.11-rc2 has been released. This is a release candidate for the 7.11 development release. >>> >>> I've tried to compile this one >>> 996aea3cca40bb34c0a9027411924879 MesaGLUT-7.11-rc2.tar.bz2 >>> >>> After unpacking >>> >>> ./configure --prefix=/opt/mesa PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig >>> LC_ALL=C make -j8 >>> >>> Make fails here > >> nv04_pushbuf.h is included in libdrm/nouveau. It doesn't look like you >> have it installed. > > Indeed it isn't installed anywhere in /opt (also not in /usr). > Btw. the latest git mesa main compiles without it beeing there. > > Alright, on the same system in ~/source/libdrm-2.4.26/ > > ./configure --prefix=/opt/mesa \ > LDFLAGS=-L/opt/mesa/lib \ > PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig > > finishes with > > ... > libdrm 2.4.26 will be compiled with: > > libkms yes > Intel API yes > vmwgfx API no > Radeon API yes > Nouveau API no > ... > > The Noveau API doesn't get installed after the autodetection. I don't think there is any autodetection involved. You must add the --enable-nouveau-experimental-api option, otherwise none of the nouveau stuff is compiled/installed. Marek > This is a Debian/Squeeze system with a self-compiled > 2.6.38 kernel and a RV570 card. > Maybe something is missing or too old for Nouveau. > > Sebastian > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] glsl: Create a standalone executable for testing optimization passes.
On 07/20/2011 08:00 AM, Chad Versace wrote: > On the issue of std::stringbuf, I'm siding with Paul here. This > concise, safe function definition: Without taking sides, I would like to point out load_text_file, which already implements this. Unfortunately, it got cut and pasted and diverged, so there's one in glsl/main.cpp and one in glsl/glcpp/glcpp.c. (That should probably be fixed.) Paul seemed to think the one in main.cpp wouldn't work with stdin, but I know for a fact the one in glcpp does. --Kenneth ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] glsl: Add unit tests for lower_jumps.cpp
On 07/18/2011 11:37 AM, Paul Berry wrote: > These tests invoke do_lower_jumps() in isolation (using the glsl_test > executable) and verify that it transforms the IR in the expected way. > > The unit tests may be run from the top level directory using "make > check". > > For reference, I've also checked in the Python script > create_test_cases.py, which was used to generate these tests. It is > not necessary to run this script in order to run the tests. > --- > Makefile |6 +- > src/glsl/tests/compare_ir | 59 ++ > src/glsl/tests/lower_jumps/.gitignore |1 + > src/glsl/tests/lower_jumps/create_test_cases.py| 643 > > src/glsl/tests/lower_jumps/lower_breaks_1.opt_test | 13 + > .../lower_jumps/lower_breaks_1.opt_test.expected |5 + > src/glsl/tests/lower_jumps/lower_breaks_2.opt_test | 15 + > .../lower_jumps/lower_breaks_2.opt_test.expected |7 + > src/glsl/tests/lower_jumps/lower_breaks_3.opt_test | 17 + > .../lower_jumps/lower_breaks_3.opt_test.expected |8 + > src/glsl/tests/lower_jumps/lower_breaks_4.opt_test | 15 + > .../lower_jumps/lower_breaks_4.opt_test.expected |7 + > src/glsl/tests/lower_jumps/lower_breaks_5.opt_test | 16 + > .../lower_jumps/lower_breaks_5.opt_test.expected |7 + > src/glsl/tests/lower_jumps/lower_breaks_6.opt_test | 29 + > .../lower_jumps/lower_breaks_6.opt_test.expected | 29 + > .../lower_guarded_conditional_break.opt_test | 21 + > ...wer_guarded_conditional_break.opt_test.expected | 20 + > .../lower_jumps/lower_pulled_out_jump.opt_test | 28 + > .../lower_pulled_out_jump.opt_test.expected| 25 + > .../tests/lower_jumps/lower_returns_1.opt_test | 12 + > .../lower_jumps/lower_returns_1.opt_test.expected |4 + > .../tests/lower_jumps/lower_returns_2.opt_test | 13 + > .../lower_jumps/lower_returns_2.opt_test.expected |5 + > .../tests/lower_jumps/lower_returns_3.opt_test | 20 + > .../lower_jumps/lower_returns_3.opt_test.expected | 21 + > .../tests/lower_jumps/lower_returns_4.opt_test | 14 + > .../lower_jumps/lower_returns_4.opt_test.expected | 16 + > .../lower_jumps/lower_returns_main_false.opt_test | 17 + > .../lower_returns_main_false.opt_test.expected |8 + > .../lower_jumps/lower_returns_main_true.opt_test | 17 + > .../lower_returns_main_true.opt_test.expected | 13 + > .../lower_jumps/lower_returns_sub_false.opt_test | 16 + > .../lower_returns_sub_false.opt_test.expected |8 + > .../lower_jumps/lower_returns_sub_true.opt_test| 16 + > .../lower_returns_sub_true.opt_test.expected | 13 + > .../lower_jumps/lower_unified_returns.opt_test | 26 + > .../lower_unified_returns.opt_test.expected| 21 + > .../remove_continue_at_end_of_loop.opt_test| 13 + > ...emove_continue_at_end_of_loop.opt_test.expected |5 + > ..._non_void_at_end_of_loop_lower_nothing.opt_test | 16 + > ..._at_end_of_loop_lower_nothing.opt_test.expected |8 + > ...n_non_void_at_end_of_loop_lower_return.opt_test | 16 + > ...d_at_end_of_loop_lower_return.opt_test.expected | 19 + > ..._at_end_of_loop_lower_return_and_break.opt_test | 16 + > ...f_loop_lower_return_and_break.opt_test.expected | 19 + > ...turn_void_at_end_of_loop_lower_nothing.opt_test | 14 + > ..._at_end_of_loop_lower_nothing.opt_test.expected |6 + > ...eturn_void_at_end_of_loop_lower_return.opt_test | 14 + > ...d_at_end_of_loop_lower_return.opt_test.expected | 11 + > ..._at_end_of_loop_lower_return_and_break.opt_test | 14 + > ...f_loop_lower_return_and_break.opt_test.expected | 11 + > src/glsl/tests/optimization-test | 28 + > src/glsl/tests/sexps.py| 103 > 54 files changed, 1543 insertions(+), 1 deletions(-) > create mode 100755 src/glsl/tests/compare_ir > create mode 100644 src/glsl/tests/lower_jumps/.gitignore > create mode 100644 src/glsl/tests/lower_jumps/create_test_cases.py > create mode 100755 src/glsl/tests/lower_jumps/lower_breaks_1.opt_test > create mode 100644 > src/glsl/tests/lower_jumps/lower_breaks_1.opt_test.expected > create mode 100755 src/glsl/tests/lower_jumps/lower_breaks_2.opt_test > create mode 100644 > src/glsl/tests/lower_jumps/lower_breaks_2.opt_test.expected > create mode 100755 src/glsl/tests/lower_jumps/lower_breaks_3.opt_test > create mode 100644 > src/glsl/tests/lower_jumps/lower_breaks_3.opt_test.expected > create mode 100755 src/glsl/tests/lower_jumps/lower_breaks_4.opt_test > create mode 100644 > src/glsl/tests/lower_jumps/lower_breaks_4.opt_test.expected > create mode 100755 src/glsl/tests/lower_jumps/lower_breaks_5.opt_test > create mode 100644 > src/glsl/tests/lower_jumps/lower_breaks_5.opt_test.expected > create mode 100755 src/glsl/tests/lower_jumps/lower_breaks_6.opt_test > crea
Re: [Mesa-dev] [PATCH 3/4] glsl: Create a standalone executable for testing optimization passes.
On 20 July 2011 08:50, Kenneth Graunke wrote: > Without taking sides, I would like to point out load_text_file, which > already implements this. Unfortunately, it got cut and pasted and > diverged, so there's one in glsl/main.cpp and one in glsl/glcpp/glcpp.c. > (That should probably be fixed.) Paul seemed to think the one in > main.cpp wouldn't work with stdin, but I know for a fact the one in > glcpp does. Thanks for pointing this out, Kenneth. I wasn't aware of the function in glcpp.c, and you're right, load_text_fp() looks like it would work just fine with stdin. It also has a few advantages over the strawman C implementation of read_stdin_to_eof() I sent to the list yesterday (namely, it avoids some unnecessary copying, it checks for memory allocation failure, and it grows its buffer size by factors of 2, which is likely to be a huge win for large files). It has a memory leak in its failure handling code (if the call to reralloc_size() fails, it never frees the original block of memory), but this is unlikely to cause problems in practice. I still prefer the 3-line C++ implementation of read_stdin_to_eof() to the 20-some lines of load_text_fp(), but if the consensus is against me, I'd be willing to rework my patch to call lord_text_fp(), in the interest of not bike-shedding this any longer. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glsl: Move initialize_context() to glsl_parser_extras.cpp so it can be re-used.
On 18 July 2011 18:13, Kenneth Graunke wrote: >> + ctx->Extensions.ARB_ES2_compatibility = GL_TRUE; >> + ctx->Extensions.ARB_draw_buffers = GL_TRUE; >> + ctx->Extensions.ARB_draw_instanced = GL_TRUE; >> + ctx->Extensions.ARB_fragment_coord_conventions = GL_TRUE; >> + ctx->Extensions.EXT_texture_array = GL_TRUE; >> + ctx->Extensions.NV_texture_rectangle = GL_TRUE; >> + ctx->Extensions.EXT_texture3D = GL_TRUE; > > Would you mind converting these to "true" as long as you're moving them? Sure, no problem. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.11 release candidate 2
>> Indeed it isn't installed anywhere in /opt (also not in /usr). >> Btw. the latest git mesa main compiles without it beeing there. >> >> Alright, on the same system in ~/source/libdrm-2.4.26/ >> >> ./configure --prefix=/opt/mesa \ >>LDFLAGS=-L/opt/mesa/lib \ >>PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig >> >> finishes with >> >> ... >> libdrm 2.4.26 will be compiled with: >> >> libkms yes >> Intel API yes >> vmwgfx API no >> Radeon API yes >> Nouveau APIno >> ... >> >> The Noveau API doesn't get installed after the autodetection. > > I don't think there is any autodetection involved. You must add the > --enable-nouveau-experimental-api option, otherwise none of the > nouveau stuff is compiled/installed. Ok, with that flag activated the Nouveau headers get installed and Mesa compiles. Thanks for the help! Sebastian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glsl: Move initialize_context() to glsl_parser_extras.cpp so it can be re-used.
On 20 July 2011 07:55, Chad Versace wrote: >> + ctx->Const.GLSLVersion = 120; >> + >> + /* 1.10 minimums. */ >> + ctx->Const.MaxLights = 8; > > There is conflict here. The GLSL vrsion is 1.20, but the comment says 1.10. > The minimum values below are identical for both versions, so I can't determine > which is correct---1.10 or 1.20. Hmm, the function that was the source of this refactor (initialize_context in glsl/main.cpp) was even worse--it set the GLSL version to 1.30, yet had a comment saying "1.10 minimums". I will need to do more digging to figure out what is correct. I'll get back to you. >> + ctx->Const.MaxDrawBuffers = 2; > ^^^ > > For GLSL 1.10 and 1.20, the minimum gl_MaxDrawBuffers is 1. > Is there a reason why you chose 2? If so, it should be > documented why you deviated from the minimum value. No reason other than an oversight. The function that was the source of the refactor overrode the 1.10 minimums in a few cases, for reasons that were not always documented. I tried to make my new function set everything to the correct minimums, and have the code in glsl/main.cpp override just the ones that it needed to override, but it looks like I missed MaxDrawBuffers. I'll fix it so that initialize_context sets the correct minimum and glsl/main.cpp overrides it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965: Enable the PIPE_CONTROL workaround workaround out of paranoia.
On Tue, 19 Jul 2011 22:11:27 -0700, Kenneth Graunke
wrote:
> On 07/19/2011 03:44 PM, Eric Anholt wrote:
> > There's scary stuff going on in PIPE_CONTROL internals, and if the
> > BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
> > it because we'll probably never be able to debug it after the fact.
> > ---
> > src/mesa/drivers/dri/intel/intel_batchbuffer.c | 32
> > +--
> > 1 files changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > index 9c97ef2..6a5f934 100644
> > --- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > +++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > @@ -308,12 +308,30 @@ emit:
> > * [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable
> > * =1, a PIPE_CONTROL with any non-zero post-sync-op is required.
> > *
> > - * XXX: There is also a workaround that would appear to apply to this
> > - * workaround, but it doesn't appear to be necessary so far:
> > + * And the workaround for these two requires this workaround first:
> > *
> > - * Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
> > + * [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
> > * BEFORE the pipe-control with a post-sync op and no write-cache
> > * flushes.
> > + *
> > + * And this last workaround is tricky because of the requirements on
> > + * that bit. From section 1.4.7.2.3 "Stall" of the Sandy Bridge PRM
> > + * volume 2 part 1:
>
> You mean 1.7.4.2.3. For that matter, I think the earlier reference
> ("implementing two workarounds on gen6. From section 1.4.7.1") should be
> 1.7.4.1 as well.
>
> > + *
> > + * "1 of the following must also be set:
> > + * - Render Target Cache Flush Enable ([12] of DW1)
> > + * - Depth Cache Flush Enable ([0] of DW1)
> > + * - Stall at Pixel Scoreboard ([1] of DW1)
> > + * - Depth Stall ([13] of DW1)
> > + * - Post-Sync Operation ([13] of DW1)
> > + * - Notify Enable ([8] of DW1)"
> > + *
> > + * The cache flushes require the workaround flush that triggered this
> > + * one, so we can't use it. Post-sync nonzero is what triggered this
> > + * workaround, so we can't use that one either. Notify enable is
> > + * IRQs, which aren't really our business. That leaves depth stall or
> > + * stall at scoreboard. It shouldn't matter which we choose because
> > + * we're supposed to be stalling the entire pipeline anyway.
>
> It seems like depth stall should be eliminated, too. Workaround 1:
> "Before any depth stall flush [...] send a PIPE_CONTROL with no bits set
> except Post-Sync Operation != 0". So we'd have to do that. But then we
> hit Workaround 3 again---this very text says we need a CS stall...with
> depth or scoreboard stall. If a depth stall...refer to rule 1.
> Repeat...infinitely.
>
> Perhaps I'm misreading...or it doesn't apply since we don't care about
> the effects of the depth stall (we're just required to set the bit).
>
> Anyway, it seems like Stall at Pixel Scoreboard might be the safer bet, no?
Agreed!
pgpw8XU9d5MRw.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39209] [bisected] Wrong display after "prefer native texture formats when possible" commit - part2
https://bugs.freedesktop.org/show_bug.cgi?id=39209 --- Comment #9 from Emil Velikov 2011-07-20 11:08:40 PDT --- Hi Victor Can you please test the latest mesa/master A patch that should resolve your issue has been pushed [1] Cheers Emil [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=d84791a72b33f96fab54ff2399e8053c50205454 -- 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] [PATCH 3/3] i965: Apply a homebrew workaround for GPU hang in OGLC api-texcoord.
On Wed, 20 Jul 2011 01:25:40 +0100, Chris Wilson wrote: > On Tue, 19 Jul 2011 15:44:12 -0700, Eric Anholt wrote: > > The behavior of flushes in the hardware is a maze of twisty passages, > > and strangely the VS constants appear to be loaded during a pipeline > > flush instead of at the time of the packet emit according to the > > simulator. On moving the STATE_BASE_ADDRESS packet to where it really > > needed to live (in order for data loads by other packets to be > > correct), we sometimes no longer got a flush between those packets > > where we apparently needed it. This replicates the flushes implied by > > a STATE_BASE_ADDRESS update, fixing the GPU hangs in OGLC and the > > "engine" demo. > > Whilst you are deep in flushing territory, do you know of any similar > rules regarding 3DSTATE_CC_STATE_POINTERS? rendercheck demands a NP or > flush before the blend mode is changed. > -Chris Haven't seen anything to do with that, other than "got to redo this when you STATE_BASE_ADDRESS". pgptkLlFFNavK.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: fix timer query on gen6+
On 07/20/2011 09:12 AM, Zou Nan hai wrote:
> on gen6+, PIPE_CONTROL reported time stamp are 64 bits
> value (high 32 bits MBZ on snb), toggles every 80 ns.
>
> Signed-off-by: Zou Nan hai
This seems correct to me. The Sandybridge PRM, Volume 1, Part 3,
section 1.1.10.10 "TIMESTAMP - Reported Timestamp Count", does seem to
agree with your code. The Ironlake PRM seems to have inaccurate info
(it lists the SNB field as Project: All), but the G45 PRM, Volume 1a,
section 8.16.10 does have the old U64 version.
That said, I haven't found the justification for the * 1000, nor why
we're only using 32-bits of the U64 counter (in the pre-gen6 code).
Please include spec references for things like this, it makes it a lot
easier to verify the changes.
--Kenneth
> ---
> src/mesa/drivers/dri/i965/brw_queryobj.c | 17 -
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
> b/src/mesa/drivers/dri/i965/brw_queryobj.c
> index b41d05d..2e04fc2 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
> @@ -47,7 +47,7 @@
>
> /** Waits on the query object's BO and totals the results for this query */
> static void
> -brw_queryobj_get_results(struct brw_query_object *query)
> +brw_queryobj_get_results(struct brw_query_object *query, int gen)
> {
> int i;
> uint64_t *results;
> @@ -58,7 +58,10 @@ brw_queryobj_get_results(struct brw_query_object *query)
> drm_intel_bo_map(query->bo, GL_FALSE);
> results = query->bo->virtual;
> if (query->Base.Target == GL_TIME_ELAPSED_EXT) {
> - query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >> 32));
> + if (gen >= 6)
> + query->Base.Result += 80 * (results[1] - results[0]);
> + else
> + query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >>
> 32));
> } else {
>/* Map and count the pixels from the current query BO */
>for (i = query->first_index; i <= query->last_index; i++) {
> @@ -200,17 +203,21 @@ brw_end_query(struct gl_context *ctx, struct
> gl_query_object *q)
> static void brw_wait_query(struct gl_context *ctx, struct gl_query_object *q)
> {
> struct brw_query_object *query = (struct brw_query_object *)q;
> + struct brw_context *brw = brw_context(ctx);
> + struct intel_context *intel = intel_context(ctx);
>
> - brw_queryobj_get_results(query);
> + brw_queryobj_get_results(query, intel->gen);
> query->Base.Ready = GL_TRUE;
> }
>
> static void brw_check_query(struct gl_context *ctx, struct gl_query_object
> *q)
> {
> struct brw_query_object *query = (struct brw_query_object *)q;
> + struct brw_context *brw = brw_context(ctx);
> + struct intel_context *intel = intel_context(ctx);
>
> if (query->bo == NULL || !drm_intel_bo_busy(query->bo)) {
> - brw_queryobj_get_results(query);
> + brw_queryobj_get_results(query, intel->gen);
>query->Base.Ready = GL_TRUE;
> }
> }
> @@ -295,7 +302,7 @@ brw_emit_query_begin(struct brw_context *brw)
>
> if (query->bo != brw->query.bo) {
>if (query->bo != NULL)
> - brw_queryobj_get_results(query);
> + brw_queryobj_get_results(query, intel->gen);
>drm_intel_bo_reference(brw->query.bo);
>query->bo = brw->query.bo;
>query->first_index = brw->query.index;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glsl: Move initialize_context() to glsl_parser_extras.cpp so it can be re-used.
On 20 July 2011 09:52, Paul Berry wrote: > On 20 July 2011 07:55, Chad Versace wrote: >>> + ctx->Const.GLSLVersion = 120; >>> + >>> + /* 1.10 minimums. */ >>> + ctx->Const.MaxLights = 8; >> >> There is conflict here. The GLSL vrsion is 1.20, but the comment says 1.10. >> The minimum values below are identical for both versions, so I can't >> determine >> which is correct---1.10 or 1.20. > > Hmm, the function that was the source of this refactor > (initialize_context in glsl/main.cpp) was even worse--it set the GLSL > version to 1.30, yet had a comment saying "1.10 minimums". I will > need to do more digging to figure out what is correct. I'll get back > to you. Ok, I've figured out what's going on here. We're initializing a stub context to be used by the standalone GLSL compiler as it compiles built-ins, and by the unit testing code as it tests optimization passes. The values we plug into ctx->Const... normally tell the GLSL compiler about the limits of the underlying driver/hardware. However, since we are doing a standalone compile, there isn't any driver or hardware, so it hardly matters what values we plug into these constants, provided that the built-ins and test cases we are compiling don't depend on them (and to my knowledge, they don't). Still, it seems sensible to set the values to the minimum values guaranteed by GLSL 1.20, since that's the largest version of GLSL that Mesa currently supports. The code was already consistent with that except for the misleading "1.10 minimums" comment (and MaxDrawBuffers, which we already discussed), so I'll just change the comment to say "1.20 minimums". ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: GLES2 should return different error enums for invalid fbo queries
Alright, here's an updated patch:
---
src/mesa/main/fbobject.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 8496936..82eb7fb 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2134,10 +2134,14 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
{
const struct gl_renderbuffer_attachment *att;
struct gl_framebuffer *buffer;
+ GLenum err;
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END(ctx);
+ /* The error differs in GL and GLES. */
+ err = ctx->API == API_OPENGL ? GL_INVALID_OPERATION : GL_INVALID_ENUM;
+
buffer = get_framebuffer_target(ctx, target);
if (!buffer) {
_mesa_error(ctx, GL_INVALID_ENUM,
@@ -2188,7 +2192,12 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
}
else {
assert(att->Type == GL_NONE);
- *params = 0;
+ if (ctx->API == API_OPENGL) {
+*params = 0;
+ } else {
+_mesa_error(ctx, GL_INVALID_ENUM,
+"glGetFramebufferAttachmentParameterivEXT(pname)");
+ }
}
return;
case GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL_EXT:
@@ -2196,7 +2205,7 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
*params = att->TextureLevel;
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, err,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2214,7 +2223,7 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
}
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, err,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2232,7 +2241,7 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
}
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, err,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2246,7 +2255,7 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, err,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2267,7 +2276,7 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
return;
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, err,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else {
@@ -2301,7 +2310,7 @@
_mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
attachment,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else if (att->Type == GL_NONE) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
+ _mesa_error(ctx, err,
"glGetFramebufferAttachmentParameterivEXT(pname)");
}
else if (att->Texture) {
--
1.7.4.1
On Wed, Jul 20, 2011 at 2:27 AM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/18/2011 06:11 PM, Marek Olšák wrote:
>> ES 2.0.25 page 127 says:
>>
>> If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
>> querying any other pname will generate INVALID_ENUM.
>
> Hurray for be different just for the sake of being different!
>
>> See also:
>> b9e9df78a03edb35472c2e231aef4747e09db792
>>
>> NOTE: This is a candidate for the 7.10 and 7.11 branches.
>> ---
>> src/mesa/main/fbobject.c | 22 +++---
>> 1 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>> index 8496936..1e11513 100644
>> --- a/src/mesa/main/fbobject.c
>> +++ b/src/mesa/main/fbobject.c
>> @@ -2134,10 +2134,13 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
>> target, GLenum attachment,
>> {
>> const struct gl_renderbuffer_attachment *att;
>> struct gl_framebuffer *buffer;
>> + GLboolean is_gl;
>> GET_CURRENT_CONTEXT(ctx);
>>
>> ASSERT_OUTSIDE_BEGIN_END(ctx);
>>
>> + is_gl = ctx->API == API_OPENGL;
>> +
>
> Maybe this would be better
>
> GLenum err = (ctx->API == API_OPENGL) ? GL_INVALID_OPERATION :
> GL_INVALID_ENUM;
>
> Every time I look at error generation code in Mesa, I feel a little ill.
> It always ends up being so much ugly code. meh.
>
>> buffer = get_framebuffer_target(ctx, target);
>> if (!buffer) {
>>
[Mesa-dev] [Bug 39209] [bisected] Wrong display after "prefer native texture formats when possible" commit - part2
https://bugs.freedesktop.org/show_bug.cgi?id=39209 Victor Tseng changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Victor Tseng 2011-07-20 14:49:19 PDT --- commit d84791a72b33f96fab54ff2399e8053c50205454 does address this bug. -- 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
[Mesa-dev] Patches to make Gallium drivers respect the force_s3tc_enable environment variable
The purpose of the following two patches is to make st/mesa expose the S3TC extensions when the force_s3tc_enable environment variable is used. This is to match the behavior of the DRI drivers, in which force_s3tc_enable is an option in driconf. Although st/mesa can't use the driconf functions, it can at least respect the environment variable for this option. These patches have been tested with fs2_open 3.6.12 and the Freespace 2 MediaVPs. Setting force_s3tc_enable=true makes the game run flawlessly without libtxc_dxtn, whereas without it the game writes several error messages to its log file and then crashes. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/mesa: respect force_s3tc_enable environment variable
---
src/mesa/state_tracker/st_extensions.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 99b231d..073e72c 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -208,6 +208,16 @@ void st_init_limits(struct st_context *st)
}
+static int st_get_s3tc_override(void)
+{
+ const char *override = _mesa_getenv("force_s3tc_enable");
+ fprintf(stderr, "force_s3tc_enable=%s\n", override);
+ if (override && !strcmp(override, "true"))
+ return GL_TRUE;
+ return GL_FALSE;
+}
+
+
/**
* Use pipe_screen::get_param() to query PIPE_CAP_ values to determine
* which GL extensions are supported.
@@ -426,7 +436,7 @@ void st_init_extensions(struct st_context *st)
if (screen->is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA,
PIPE_TEXTURE_2D, 0,
PIPE_BIND_SAMPLER_VIEW) &&
- ctx->Mesa_DXTn) {
+ (ctx->Mesa_DXTn || st_get_s3tc_override())) {
ctx->Extensions.EXT_texture_compression_s3tc = GL_TRUE;
ctx->Extensions.S3_s3tc = GL_TRUE;
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] util: enable S3TC support when the force_s3tc_enable env var is set to "true"
---
src/gallium/auxiliary/util/u_format_s3tc.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
b/src/gallium/auxiliary/util/u_format_s3tc.c
index bb989c2..d8a7c0d 100644
--- a/src/gallium/auxiliary/util/u_format_s3tc.c
+++ b/src/gallium/auxiliary/util/u_format_s3tc.c
@@ -119,8 +119,15 @@ util_format_s3tc_init(void)
library = util_dl_open(DXTN_LIBNAME);
if (!library) {
- debug_printf("couldn't open " DXTN_LIBNAME ", software DXTn "
- "compression/decompression unavailable\n");
+ if (getenv("force_s3tc_enable") &&
+ !strcmp(getenv("force_s3tc_enable"), "true")) {
+ debug_printf("couldn't open " DXTN_LIBNAME ", enabling DXTn due to "
+"force_s3tc_enable=true environment variable\n");
+ util_format_s3tc_enabled = TRUE;
+ } else {
+ debug_printf("couldn't open " DXTN_LIBNAME ", software DXTn "
+"compression/decompression unavailable\n");
+ }
return;
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/8] glsl: Rework lowering of non-constant array indexing
On Mon, 18 Jul 2011 14:15:22 -0700, "Ian Romanick" wrote:
> From: Ian Romanick
>
> The previous implementation could easily get tricked if the LHS of an
> assignment included a non-constant index that was "inside" another
> dereference. For example:
>
> mat4 m[2];
> m[0][i] = vec4(0.0);
>
> Due to the way it tracked whether the array was being assigned, it
> would think that the non-constant index was in an r-value. The new
> code fixes that by tracking l-values and r-values differently. The
> index is also replaced by cloning the IR and replacing the index
> variable instead of the odd way it was done before.
>
> Fixes i965 piglit fs-temp-array-mat[234]-index-wr and
> vs-varying-array-mat[234]-index-wr.
I think I see one little simplification, and other than that I think
I've made sense of it.
> struct assignment_generator
> {
> ir_instruction* base_ir;
> - ir_rvalue* array;
> + ir_rvalue *rvalue;
I think this rvalue could be an ir_dereference *
> + ir_variable *old_index;
> bool is_write;
> unsigned int write_mask;
> ir_variable* var;
> @@ -61,14 +136,25 @@ struct assignment_generator
> * underlying variable.
> */
>void *mem_ctx = ralloc_parent(base_ir);
> - ir_dereference *element =
> - new(mem_ctx) ir_dereference_array(this->array->clone(mem_ctx, NULL),
> -new(mem_ctx) ir_constant(i));
> - ir_rvalue *variable = new(mem_ctx) ir_dereference_variable(this->var);
>
> + /* Clone the old r-value in its entirety. Then replace any occurances
> of
> + * the old variable index with the new constant index.
> + */
> + ir_rvalue *element = this->rvalue->clone(mem_ctx, NULL);
Making this an ir_dereference *
> + ir_constant *const index = new(mem_ctx) ir_constant(i);
> + deref_replacer r(this->old_index, index);
> + element->accept(&r);
> + assert(r.progress);
> +
> + /* Generate a conditional assignment to (or from) the constant indexed
> + * array dereference.
> + */
> + ir_rvalue *variable = new(mem_ctx) ir_dereference_variable(this->var);
>ir_assignment *assignment;
>if (is_write) {
> - assignment = new(mem_ctx) ir_assignment(element, variable, condition,
> + ir_dereference *d = element->as_dereference();
> + assert(d != NULL);
> + assignment = new(mem_ctx) ir_assignment(d, variable, condition,
>write_mask);
And avoiding this cast/assert...
> ir_variable *convert_dereference_array(ir_dereference_array *orig_deref,
> - ir_assignment* orig_assign)
> + ir_assignment* orig_assign,
> + ir_rvalue *orig_base)
> {
>assert(is_array_or_matrix(orig_deref->array));
>
> @@ -320,9 +407,12 @@ public:
>new(mem_ctx) ir_assignment(lhs, orig_deref->array_index, NULL);
>base_ir->insert_before(assign);
>
> + orig_deref->array_index = lhs->clone(mem_ctx, NULL);
> +
>assignment_generator ag;
> - ag.array = orig_deref->array;
> + ag.rvalue = orig_base;
>ag.base_ir = base_ir;
> + ag.old_index = index;
>ag.var = var;
>if (orig_assign) {
>ag.is_write = true;
> @@ -342,12 +432,16 @@ public:
>
> virtual void handle_rvalue(ir_rvalue **pir)
> {
> + if (this->in_assignee)
> + return;
> +
>if (!*pir)
> return;
>
>ir_dereference_array* orig_deref = (*pir)->as_dereference_array();
>if (needs_lowering(orig_deref)) {
> - ir_variable* var = convert_dereference_array(orig_deref, 0);
> + ir_variable *var =
> + convert_dereference_array(orig_deref, NULL, orig_deref);
> assert(var);
> *pir = new(ralloc_parent(base_ir)) ir_dereference_variable(var);
> this->progress = true;
> @@ -359,10 +453,11 @@ public:
> {
>ir_rvalue_visitor::visit_leave(ir);
>
> - ir_dereference_array *orig_deref = ir->lhs->as_dereference_array();
> + find_variable_index f;
> + ir->lhs->accept(&f);
>
> - if (needs_lowering(orig_deref)) {
> - convert_dereference_array(orig_deref, ir);
> + if ((f.deref != NULL) && storage_type_needs_lowering(f.deref)) {
> + convert_dereference_array(f.deref, ir, ir->lhs);
> ir->remove();
> this->progress = true;
>}
Because the orig_base of both convert_dereference_array() calls is a
deref.
I think it's nice to note that this is a dereference because it means
that clone()ing should be safer than, say, cloning some expression tree.
pgpBpnJtPDJim.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: Reject shaders that contain static recursion
On 07/17/2011 01:03 PM, Ian Romanick wrote: > From: Ian Romanick > > The GLSL 1.20 and later specs say: > > "Recursion is not allowed, not even statically. Static recursion is > present if the static function call graph of the program contains > cycles." > > Recursion is detected and rejected both a compile-time and at > link-time. The complie-time check happens to detect some cases that > may be removed by various optimization passes. The spec doesn't seem > to allow this, but other vendors (e.g., NVIDIA) appear to only check > at link-time after all optimizations. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33885 > --- > src/glsl/Makefile |1 + > src/glsl/ast_to_hir.cpp |2 + > src/glsl/ir.h | 26 ++ > src/glsl/ir_function_detect_recursion.cpp | 356 > + > src/glsl/linker.cpp |4 + > 5 files changed, 389 insertions(+), 0 deletions(-) > create mode 100644 src/glsl/ir_function_detect_recursion.cpp > > diff --git a/src/glsl/Makefile b/src/glsl/Makefile > index e0776c1..d1422c2 100644 > --- a/src/glsl/Makefile > +++ b/src/glsl/Makefile > @@ -39,6 +39,7 @@ CXX_SOURCES = \ > ir.cpp \ > ir_expression_flattening.cpp \ > ir_function_can_inline.cpp \ > + ir_function_detect_recursion.cpp \ > ir_function.cpp \ > ir_hierarchical_visitor.cpp \ > ir_hv_accept.cpp \ > diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp > index 2e54e8c..843d755 100644 > --- a/src/glsl/ast_to_hir.cpp > +++ b/src/glsl/ast_to_hir.cpp > @@ -83,6 +83,8 @@ _mesa_ast_to_hir(exec_list *instructions, struct > _mesa_glsl_parse_state *state) > > foreach_list_typed (ast_node, ast, link, & state->translation_unit) >ast->hir(instructions, state); > + > + detect_recursion_unlinked(state, instructions); > } > > > diff --git a/src/glsl/ir.h b/src/glsl/ir.h > index 9f27738..50a9d6e 100644 > --- a/src/glsl/ir.h > +++ b/src/glsl/ir.h > @@ -1635,6 +1635,32 @@ visit_exec_list(exec_list *list, ir_visitor *visitor); > */ > void validate_ir_tree(exec_list *instructions); > > +struct _mesa_glsl_parse_state; > +struct gl_shader_program; > + > +/** > + * Detect whether an unlinked shader contains static recursion > + * > + * If the list of instructions is determined to contain static recursion, > + * \c _mesa_glsl_error will be called to emit error messages for each > function > + * that is in the recursion cycle. > + */ > +void > +detect_recursion_unlinked(struct _mesa_glsl_parse_state *state, > + exec_list *instructions); > + > +/** > + * Detect whether a linked shader contains static recursion > + * > + * If the list of instructions is determined to contain static recursion, > + * \c link_error_printf will be called to emit error messages for each > function > + * that is in the recursion cycle. In addition, > + * \c gl_shader_program::LinkStatus will be set to false. > + */ > +void > +detect_recursion_linked(struct gl_shader_program *prog, > + exec_list *instructions); > + > /** > * Make a clone of each IR instruction in a list > * > diff --git a/src/glsl/ir_function_detect_recursion.cpp > b/src/glsl/ir_function_detect_recursion.cpp > new file mode 100644 > index 000..b82c659 > --- /dev/null > +++ b/src/glsl/ir_function_detect_recursion.cpp > @@ -0,0 +1,356 @@ > +/* > + * Copyright © 2011 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the next > + * paragraph) shall be included in all copies or substantial portions of the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. > + */ > + > +/** > + * \file ir_function_detect_recursion.cpp > + * Determine whether a shader contains static recursion. > + * > + * Consider the (possibly disjoint) graph of function calls in a shader. If > a > + * program contains recursion, this graph will contain a cycle. If a > function > + * is part of
Re: [Mesa-dev] [PATCH 0/8] Fix non-constant array-of-matrix accesses
On Mon, 18 Jul 2011 14:15:19 -0700, "Ian Romanick" wrote: > As can be seen from the giant pile of tests recently sent to the > piglit mailing list for review, the > lower_variable_index_to_cond_assign pass had some issues. With this > patch series, *all* of the variable indexing tests posted to the > piglit list pass with (classic) swrast. 102 additional tests pass on > the i965 driver. > > See also: http://people.freedesktop.org/~idr/variable-indexing-results/ Other than the one comment, Reviewed-by: Eric Anholt (and also for that patch as well, regardless) pgpGHOt4gTXVt.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: GLES2 should return different error enums for invalid fbo queries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/20/2011 01:38 PM, Marek Olšák wrote:
> Alright, here's an updated patch:
Reviewed-by: Ian Romanick
> ---
> src/mesa/main/fbobject.c | 23 ---
> 1 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 8496936..82eb7fb 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2134,10 +2134,14 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
> {
> const struct gl_renderbuffer_attachment *att;
> struct gl_framebuffer *buffer;
> + GLenum err;
> GET_CURRENT_CONTEXT(ctx);
>
> ASSERT_OUTSIDE_BEGIN_END(ctx);
>
> + /* The error differs in GL and GLES. */
> + err = ctx->API == API_OPENGL ? GL_INVALID_OPERATION : GL_INVALID_ENUM;
> +
> buffer = get_framebuffer_target(ctx, target);
> if (!buffer) {
>_mesa_error(ctx, GL_INVALID_ENUM,
> @@ -2188,7 +2192,12 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
>}
>else {
> assert(att->Type == GL_NONE);
> - *params = 0;
> + if (ctx->API == API_OPENGL) {
> +*params = 0;
> + } else {
> +_mesa_error(ctx, GL_INVALID_ENUM,
> +"glGetFramebufferAttachmentParameterivEXT(pname)");
> + }
>}
>return;
> case GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL_EXT:
> @@ -2196,7 +2205,7 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
>*params = att->TextureLevel;
>}
>else if (att->Type == GL_NONE) {
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> + _mesa_error(ctx, err,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else {
> @@ -2214,7 +2223,7 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
> }
>}
>else if (att->Type == GL_NONE) {
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> + _mesa_error(ctx, err,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else {
> @@ -2232,7 +2241,7 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
> }
>}
>else if (att->Type == GL_NONE) {
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> + _mesa_error(ctx, err,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else {
> @@ -2246,7 +2255,7 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else if (att->Type == GL_NONE) {
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> + _mesa_error(ctx, err,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else {
> @@ -2267,7 +2276,7 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
> return;
>}
>else if (att->Type == GL_NONE) {
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> + _mesa_error(ctx, err,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else {
> @@ -2301,7 +2310,7 @@
> _mesa_GetFramebufferAttachmentParameterivEXT(GLenum target, GLenum
> attachment,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else if (att->Type == GL_NONE) {
> - _mesa_error(ctx, GL_INVALID_OPERATION,
> + _mesa_error(ctx, err,
> "glGetFramebufferAttachmentParameterivEXT(pname)");
>}
>else if (att->Texture) {
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4nfu8ACgkQX1gOwKyEAw+gNgCfeC12yH8X74aaviEe3iz/MTy1
3i8An3PrjeMSsok7Co0EWpqr8KzLn5RJ
=di+b
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: fix timer query on gen6+
For ILK, It is vol 1.18.11.2,
This register has the contents from TIMESTAMP_HI (0x70070)
display register. This field gets incremented every 1 uS of time.
Thanks
Zou Nanhai
-Original Message-
From: mesa-dev-bounces+nanhai.zou=intel@lists.freedesktop.org
[mailto:mesa-dev-bounces+nanhai.zou=intel@lists.freedesktop.org] On Behalf
Of Kenneth Graunke
Sent: 2011年7月21日 2:13
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] i965: fix timer query on gen6+
On 07/20/2011 09:12 AM, Zou Nan hai wrote:
> on gen6+, PIPE_CONTROL reported time stamp are 64 bits
> value (high 32 bits MBZ on snb), toggles every 80 ns.
>
> Signed-off-by: Zou Nan hai
This seems correct to me. The Sandybridge PRM, Volume 1, Part 3,
section 1.1.10.10 "TIMESTAMP - Reported Timestamp Count", does seem to
agree with your code. The Ironlake PRM seems to have inaccurate info
(it lists the SNB field as Project: All), but the G45 PRM, Volume 1a,
section 8.16.10 does have the old U64 version.
That said, I haven't found the justification for the * 1000, nor why
we're only using 32-bits of the U64 counter (in the pre-gen6 code).
Please include spec references for things like this, it makes it a lot
easier to verify the changes.
--Kenneth
> ---
> src/mesa/drivers/dri/i965/brw_queryobj.c | 17 -
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
> b/src/mesa/drivers/dri/i965/brw_queryobj.c
> index b41d05d..2e04fc2 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
> @@ -47,7 +47,7 @@
>
> /** Waits on the query object's BO and totals the results for this query */
> static void
> -brw_queryobj_get_results(struct brw_query_object *query)
> +brw_queryobj_get_results(struct brw_query_object *query, int gen)
> {
> int i;
> uint64_t *results;
> @@ -58,7 +58,10 @@ brw_queryobj_get_results(struct brw_query_object *query)
> drm_intel_bo_map(query->bo, GL_FALSE);
> results = query->bo->virtual;
> if (query->Base.Target == GL_TIME_ELAPSED_EXT) {
> - query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >> 32));
> + if (gen >= 6)
> + query->Base.Result += 80 * (results[1] - results[0]);
> + else
> + query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >>
> 32));
> } else {
>/* Map and count the pixels from the current query BO */
>for (i = query->first_index; i <= query->last_index; i++) {
> @@ -200,17 +203,21 @@ brw_end_query(struct gl_context *ctx, struct
> gl_query_object *q)
> static void brw_wait_query(struct gl_context *ctx, struct gl_query_object *q)
> {
> struct brw_query_object *query = (struct brw_query_object *)q;
> + struct brw_context *brw = brw_context(ctx);
> + struct intel_context *intel = intel_context(ctx);
>
> - brw_queryobj_get_results(query);
> + brw_queryobj_get_results(query, intel->gen);
> query->Base.Ready = GL_TRUE;
> }
>
> static void brw_check_query(struct gl_context *ctx, struct gl_query_object
> *q)
> {
> struct brw_query_object *query = (struct brw_query_object *)q;
> + struct brw_context *brw = brw_context(ctx);
> + struct intel_context *intel = intel_context(ctx);
>
> if (query->bo == NULL || !drm_intel_bo_busy(query->bo)) {
> - brw_queryobj_get_results(query);
> + brw_queryobj_get_results(query, intel->gen);
>query->Base.Ready = GL_TRUE;
> }
> }
> @@ -295,7 +302,7 @@ brw_emit_query_begin(struct brw_context *brw)
>
> if (query->bo != brw->query.bo) {
>if (query->bo != NULL)
> - brw_queryobj_get_results(query);
> + brw_queryobj_get_results(query, intel->gen);
>drm_intel_bo_reference(brw->query.bo);
>query->bo = brw->query.bo;
>query->first_index = brw->query.index;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
