[Mesa-dev] [Bug 37476] [wine] Devil May Cry 4: TXD tgsi opcode unsupported / translation from TGSI failed / missing vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=37476 --- Comment #4 from Dave Airlie 2011-06-14 23:58:39 PDT --- Hi Mike, you might have noticed I pushed something that worked, then found this patch, which I preferred to mine, so I fixed up the code with your authorship on a few patches derived from this. Please test and let me know if it works for you, as I have a few differences from your code. Dave. -- 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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 Karl Tomlinson changed: What|Removed |Added CC||bugs.freedesk...@karlt.net --- Comment #7 from Karl Tomlinson 2011-06-14 23:09:11 PDT --- Yes, sorry, there are probably a few confounding issues in the one bug report. Refer to https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c3 for glxinfo in the configuration involved here. -- 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 2/2] i965: Use state streaming on programs, and state base address on gen5+.
There will be a little bit of thrashing of the program cache BO as the
cache warms up, but once the application is in steady state, this
reduces relocations on gen5 and later.
On my T420 laptop, cairogl firefox-talos-gfx performance improves 2.6%
+/- 1.3% (n=6). No statistically significant performance difference
on nexuiz (n=5).
---
src/mesa/drivers/dri/i965/brw_clip.c | 24 ++--
src/mesa/drivers/dri/i965/brw_clip_state.c | 19 ++--
src/mesa/drivers/dri/i965/brw_context.h | 55 ++---
src/mesa/drivers/dri/i965/brw_fs.cpp |6 +-
src/mesa/drivers/dri/i965/brw_gs.c | 24 ++---
src/mesa/drivers/dri/i965/brw_gs_state.c | 19 ++--
src/mesa/drivers/dri/i965/brw_misc_state.c | 10 +-
src/mesa/drivers/dri/i965/brw_sf.c | 22 ++--
src/mesa/drivers/dri/i965/brw_sf_state.c | 15 ++-
src/mesa/drivers/dri/i965/brw_state.h| 28 ++--
src/mesa/drivers/dri/i965/brw_state_cache.c | 164 --
src/mesa/drivers/dri/i965/brw_state_dump.c | 26 ++--
src/mesa/drivers/dri/i965/brw_state_upload.c | 17 ++--
src/mesa/drivers/dri/i965/brw_vs.c | 22 ++--
src/mesa/drivers/dri/i965/brw_vs_state.c | 18 ++--
src/mesa/drivers/dri/i965/brw_vtbl.c | 12 +-
src/mesa/drivers/dri/i965/brw_wm.c | 21 ++--
src/mesa/drivers/dri/i965/brw_wm_state.c | 40 +++
src/mesa/drivers/dri/i965/gen6_gs_state.c|2 +-
src/mesa/drivers/dri/i965/gen6_urb.c |2 +-
src/mesa/drivers/dri/i965/gen6_vs_state.c|2 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c| 10 +-
src/mesa/drivers/dri/i965/gen7_disable.c |2 +-
src/mesa/drivers/dri/i965/gen7_urb.c |2 +-
src/mesa/drivers/dri/i965/gen7_vs_state.c|2 +-
src/mesa/drivers/dri/i965/gen7_wm_state.c|9 +-
26 files changed, 276 insertions(+), 297 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index c7d428b..d82206b 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -146,15 +146,12 @@ static void compile_clip_prog( struct brw_context *brw,
printf("\n");
}
- /* Upload
-*/
- drm_intel_bo_unreference(brw->clip.prog_bo);
- brw->clip.prog_bo = brw_upload_cache(&brw->cache,
- BRW_CLIP_PROG,
- &c.key, sizeof(c.key),
- program, program_size,
- &c.prog_data, sizeof(c.prog_data),
- &brw->clip.prog_data);
+ brw_upload_cache(&brw->cache,
+ BRW_CLIP_PROG,
+ &c.key, sizeof(c.key),
+ program, program_size,
+ &c.prog_data, sizeof(c.prog_data),
+ &brw->clip.prog_offset, &brw->clip.prog_data);
ralloc_free(mem_ctx);
}
@@ -271,12 +268,11 @@ static void upload_clip_prog(struct brw_context *brw)
}
}
- drm_intel_bo_unreference(brw->clip.prog_bo);
- brw->clip.prog_bo = brw_search_cache(&brw->cache, BRW_CLIP_PROG,
- &key, sizeof(key),
- &brw->clip.prog_data);
- if (brw->clip.prog_bo == NULL)
+ if (!brw_search_cache(&brw->cache, BRW_CLIP_PROG,
+&key, sizeof(key),
+&brw->clip.prog_offset, &brw->clip.prog_data)) {
compile_clip_prog( brw, &key );
+ }
}
diff --git a/src/mesa/drivers/dri/i965/brw_clip_state.c
b/src/mesa/drivers/dri/i965/brw_clip_state.c
index 6015c8c..b9efbb7 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_state.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_state.c
@@ -43,11 +43,15 @@ brw_prepare_clip_unit(struct brw_context *brw)
clip = brw_state_batch(brw, sizeof(*clip), 32, &brw->clip.state_offset);
memset(clip, 0, sizeof(*clip));
- /* CACHE_NEW_CLIP_PROG */
+ /* BRW_NEW_PROGRAM_CACHE | CACHE_NEW_CLIP_PROG */
clip->thread0.grf_reg_count = (ALIGN(brw->clip.prog_data->total_grf, 16) /
16 - 1);
- /* reloc */
- clip->thread0.kernel_start_pointer = brw->clip.prog_bo->offset >> 6;
+ clip->thread0.kernel_start_pointer =
+ brw_program_reloc(brw,
+ brw->clip.state_offset +
+ offsetof(struct brw_clip_unit_state, thread0),
+ brw->clip.prog_offset +
+ (clip->thread0.grf_reg_count << 1)) >> 6;
clip->thread1.floating_point_mode = BRW_FLOATING_POINT_NON_IEEE_754;
clip->thread1.single_program_flow = 1;
@@ -110,14 +114,6 @@ brw_prepare_clip_unit(struct brw_context *brw)
clip->viewport_ymin = -1;
clip->viewport_ymax = 1;
- /* Emit clip program relocation */
- assert(brw->clip.prog_bo);
- drm_intel_bo_emit_reloc(intel->batch.bo,
- (brw->clip.state_offset +
-
[Mesa-dev] [PATCH 1/2] i965: Only flag the new-batch related state as dirty at new batch time.
This was debug code from the initial import of the driver. No statistically significant performance difference on cairo-gl or nexuiz (n=6). --- src/mesa/drivers/dri/i965/brw_vtbl.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c b/src/mesa/drivers/dri/i965/brw_vtbl.c index 69650e1..236c4d2 100644 --- a/src/mesa/drivers/dri/i965/brw_vtbl.c +++ b/src/mesa/drivers/dri/i965/brw_vtbl.c @@ -122,11 +122,7 @@ static void brw_new_batch( struct intel_context *intel ) * This is probably not as severe as on 915, since almost all of our state * is just in referenced buffers. */ - brw->state.dirty.brw |= BRW_NEW_CONTEXT; - - brw->state.dirty.mesa |= ~0; - brw->state.dirty.brw |= ~0; - brw->state.dirty.cache |= ~0; + brw->state.dirty.brw |= BRW_NEW_CONTEXT | BRW_NEW_BATCH; brw->vb.nr_current_buffers = 0; } -- 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 (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
Ok, 1e16c34c5c86690b26739fbad82617768b1bd837 should fix the warnings for those
still using compilers based in the 1980's ;p
--Jeremy
On Jun 14, 2011, at 5:19 PM, Brian Paul wrote:
> Still no go. You need to move the snprintf() calls after the variable
> declarations.
>
> -Brian
>
> On 06/14/2011 01:33 PM, Jeremy Huddleston wrote:
>> Hi Brian,
>>
>> Please give this change a try. It should clear up the gcc -pedantic
>> warnings and also replaces the NULL entries with noops since that seems to
>> be done in other tables as well (eg: indirect_init.c).
>>
>> Thanks,
>> Jeremy
>>
>> diff --git a/src/mapi/glapi/gen/gl_gentable.py
>> b/src/mapi/glapi/gen/gl_gentable.py
>> index 73986f2..4420e3a 100644
>> --- a/src/mapi/glapi/gen/gl_gentable.py
>> +++ b/src/mapi/glapi/gen/gl_gentable.py
>> @@ -34,6 +34,10 @@ import gl_XML, glX_XML
>> import sys, getopt
>>
>> header = """
>> +#if defined(DEBUG)&& !defined(_WIN32_WCE)
>> +#include
>> +#endif
>> +
>> #include
>> #include
>> #include
>> @@ -43,6 +47,40 @@ header = """
>> #include "glapi.h"
>> #include "glapitable.h"
>>
>> +static void
>> +__glapi_gentable_NoOp(void) {
>> +#if defined(DEBUG)&& !defined(_WIN32_WCE)
>> +if (getenv("MESA_DEBUG") || getenv("LIBGL_DEBUG")) {
>> +const char *fstr = "Unknown";
>> +void *frames[2];
>> +
>> +if(backtrace(frames, 2) == 2) {
>> +Dl_info info;
>> +dladdr(frames[1],&info);
>> +if(info.dli_sname)
>> +fstr = info.dli_sname;
>> +}
>> +
>> +fprintf(stderr, "Call to unimplemented API: %s\\n", fstr);
>> +}
>> +#endif
>> +}
>> +
>> +static void
>> +__glapi_gentable_set_remaining_noop(struct _glapi_table *disp) {
>> +GLuint entries = _glapi_get_dispatch_table_size();
>> +void **dispatch = (void **) disp;
>> +int i;
>> +
>> +/* ISO C is annoying sometimes */
>> +union {_glapi_proc p; void *v;} p;
>> +p.p = __glapi_gentable_NoOp;
>> +
>> +for(i=0; i< entries; i++)
>> +if(dispatch[i] == NULL)
>> +dispatch[i] = p.v;
>> +}
>> +
>> struct _glapi_table *
>> _glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
>> struct _glapi_table *disp = calloc(1, sizeof(struct _glapi_table));
>> @@ -56,6 +94,8 @@ _glapi_create_table_from_handle(void *handle, const char
>> *symbol_prefix) {
>> """
>>
>> footer = """
>> +__glapi_gentable_set_remaining_noop(disp);
>> +
>> return disp;
>> }
>> """
>> @@ -63,8 +103,8 @@ footer = """
>> body_template = """
>> if(!disp->%(name)s) {
>> snprintf(symboln, sizeof(symboln), "%%s%(entry_point)s",
>> symbol_prefix);
>> -_glapi_proc *procp = (_glapi_proc *)&disp->%(name)s;
>> -*procp = (_glapi_proc) dlsym(handle, symboln);
>> +void ** procp = (void **)&disp->%(name)s;
>> +*procp = dlsym(handle, symboln);
>> }
>> """
>>
>>
>> On Jun 13, 2011, at 3:13 PM, Brian Paul wrote:
>>
>>> On 06/13/2011 03:53 PM, Jeremy Huddleston wrote:
b44d13e67bfe81b2d7af4aeda2c3caf7f252bd0f should work for you. Thanks for
letting me know.
>>>
>>> Another warning:
>>>
>>>
>>> glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
>>> glapi_gentable.c:54:9: warning: ISO C90 forbids mixed declarations and code
>>> glapi_gentable.c:55:18: warning: ISO C forbids conversion of object pointer
>>> to f
>>> unction pointer type
>>> glapi_gentable.c:61:9: warning: ISO C90 forbids mixed declarations and code
>>> glapi_gentable.c:62:18: warning: ISO C forbids conversion of object pointer
>>> to f
>>> unction pointer type
>>> glapi_gentable.c:68:9: warning: ISO C90 forbids mixed declarations and code
>>> glapi_gentable.c:69:18: warning: ISO C forbids conversion of object pointer
>>> to f
>>> unction pointer type
>>>
>>>
>>> Need to put the _glapi_proc declaration first.
>>>
>>> -Brian
>>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 Tony Mechelynck changed: What|Removed |Added CC||antoine.mechely...@gmail.co ||m -- 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] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
Still no go. You need to move the snprintf() calls after the variable
declarations.
-Brian
On 06/14/2011 01:33 PM, Jeremy Huddleston wrote:
Hi Brian,
Please give this change a try. It should clear up the gcc -pedantic warnings
and also replaces the NULL entries with noops since that seems to be done in
other tables as well (eg: indirect_init.c).
Thanks,
Jeremy
diff --git a/src/mapi/glapi/gen/gl_gentable.py
b/src/mapi/glapi/gen/gl_gentable.py
index 73986f2..4420e3a 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -34,6 +34,10 @@ import gl_XML, glX_XML
import sys, getopt
header = """
+#if defined(DEBUG)&& !defined(_WIN32_WCE)
+#include
+#endif
+
#include
#include
#include
@@ -43,6 +47,40 @@ header = """
#include "glapi.h"
#include "glapitable.h"
+static void
+__glapi_gentable_NoOp(void) {
+#if defined(DEBUG)&& !defined(_WIN32_WCE)
+if (getenv("MESA_DEBUG") || getenv("LIBGL_DEBUG")) {
+const char *fstr = "Unknown";
+void *frames[2];
+
+if(backtrace(frames, 2) == 2) {
+Dl_info info;
+dladdr(frames[1],&info);
+if(info.dli_sname)
+fstr = info.dli_sname;
+}
+
+fprintf(stderr, "Call to unimplemented API: %s\\n", fstr);
+}
+#endif
+}
+
+static void
+__glapi_gentable_set_remaining_noop(struct _glapi_table *disp) {
+GLuint entries = _glapi_get_dispatch_table_size();
+void **dispatch = (void **) disp;
+int i;
+
+/* ISO C is annoying sometimes */
+union {_glapi_proc p; void *v;} p;
+p.p = __glapi_gentable_NoOp;
+
+for(i=0; i< entries; i++)
+if(dispatch[i] == NULL)
+dispatch[i] = p.v;
+}
+
struct _glapi_table *
_glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
struct _glapi_table *disp = calloc(1, sizeof(struct _glapi_table));
@@ -56,6 +94,8 @@ _glapi_create_table_from_handle(void *handle, const char
*symbol_prefix) {
"""
footer = """
+__glapi_gentable_set_remaining_noop(disp);
+
return disp;
}
"""
@@ -63,8 +103,8 @@ footer = """
body_template = """
if(!disp->%(name)s) {
snprintf(symboln, sizeof(symboln), "%%s%(entry_point)s",
symbol_prefix);
-_glapi_proc *procp = (_glapi_proc *)&disp->%(name)s;
-*procp = (_glapi_proc) dlsym(handle, symboln);
+void ** procp = (void **)&disp->%(name)s;
+*procp = dlsym(handle, symboln);
}
"""
On Jun 13, 2011, at 3:13 PM, Brian Paul wrote:
On 06/13/2011 03:53 PM, Jeremy Huddleston wrote:
b44d13e67bfe81b2d7af4aeda2c3caf7f252bd0f should work for you. Thanks for
letting me know.
Another warning:
glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
glapi_gentable.c:54:9: warning: ISO C90 forbids mixed declarations and code
glapi_gentable.c:55:18: warning: ISO C forbids conversion of object pointer to f
unction pointer type
glapi_gentable.c:61:9: warning: ISO C90 forbids mixed declarations and code
glapi_gentable.c:62:18: warning: ISO C forbids conversion of object pointer to f
unction pointer type
glapi_gentable.c:68:9: warning: ISO C90 forbids mixed declarations and code
glapi_gentable.c:69:18: warning: ISO C forbids conversion of object pointer to f
unction pointer type
Need to put the _glapi_proc declaration first.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38320] Account Request for Paul Berry
https://bugs.freedesktop.org/show_bug.cgi?id=38320 Brian Paul changed: What|Removed |Added Product|Mesa|freedesktop.org Component|Other |New Accounts AssignedTo|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org --- Comment #3 from Brian Paul 2011-06-14 17:15:51 PDT --- OK. Reassigning to admins. -- 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/gen5, 6: Fix hang when emitting hiz buffer without stencil buffer
When emitting either a hiz or stencil buffer, the 'separate stencil
enable' and 'hiz enable' bits are set in 3DSTATE_DEPTH_BUFFER. Therefore
we must emit both 3DSTATE_HIER_DEPTH_BUFFER and 3DSTATE_STENCIL_BUFFER.
Even if there is no stencil buffer, 3DSTATE_STENCIL_BUFFER must be
emitted; failure to do so causes a hang on gen5 and a stall on gen6.
This also fixes a silly, obvious segfault that occured when a hiz buffer
xor separate stencil buffer existed.
Fixes the piglit tests below on Gen5 when hiz and separate stencil are
manually enabled:
fbo-alphatest-nocolor
fbo-depth-sample-compare
fbo
hiz-depth-read-fbo-d24-s0
hiz-depth-stencil-test-fbo-d24-s0
hiz-depth-test-fbo-d24-s0
hiz-stencil-read-fbo-d0-s8
hiz-stencil-test-fbo-d0-s8
fbo-missing-attachment-clear
fbo-clear-formats
fbo-depth-*
Changes piglit test result from crash to fail:
hiz-depth-stencil-test-fbo-d0-s8
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 58 +++-
1 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 3d0983e..c2063a2 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -355,26 +355,48 @@ static void emit_depthbuffer(struct brw_context *brw)
ADVANCE_BATCH();
}
- /* Emit hiz buffer. */
if (hiz_region || stencil_irb) {
- BEGIN_BATCH(3);
- OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
- OUT_BATCH(hiz_region->pitch * hiz_region->cpp - 1);
- OUT_RELOC(hiz_region->buffer,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- 0);
- ADVANCE_BATCH();
- }
+ /*
+ * In the 3DSTATE_DEPTH_BUFFER batch emitted above, the 'separate
+ * stencil enable' and 'hiz enable' bits were set. Therefore we must
+ * emit 3DSTATE_HIER_DEPTH_BUFFER and 3DSTATE_STENCIL_BUFFER. Even if
+ * there is no stencil buffer, 3DSTATE_STENCIL_BUFFER must be emitted;
+ * failure to do so causes hangs on gen5.
+ */
- /* Emit stencil buffer. */
- if (hiz_region || stencil_irb) {
- BEGIN_BATCH(3);
- OUT_BATCH((_3DSTATE_STENCIL_BUFFER << 16) | (3 - 2));
- OUT_BATCH(stencil_irb->region->pitch * stencil_irb->region->cpp - 1);
- OUT_RELOC(stencil_irb->region->buffer,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- 0);
- ADVANCE_BATCH();
+ /* Emit hiz buffer. */
+ if (hiz_region) {
+BEGIN_BATCH(3);
+OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
+OUT_BATCH(hiz_region->pitch * hiz_region->cpp - 1);
+OUT_RELOC(hiz_region->buffer,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+ 0);
+ADVANCE_BATCH();
+ } else {
+BEGIN_BATCH(3);
+OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
+OUT_BATCH(0);
+OUT_BATCH(0);
+ADVANCE_BATCH();
+ }
+
+ /* Emit stencil buffer. */
+ if (stencil_irb) {
+BEGIN_BATCH(3);
+OUT_BATCH((_3DSTATE_STENCIL_BUFFER << 16) | (3 - 2));
+OUT_BATCH(stencil_irb->region->pitch * stencil_irb->region->cpp - 1);
+OUT_RELOC(stencil_irb->region->buffer,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+ 0);
+ADVANCE_BATCH();
+ } else {
+BEGIN_BATCH(3);
+OUT_BATCH((_3DSTATE_STENCIL_BUFFER << 16) | (3 - 2));
+OUT_BATCH(0);
+OUT_BATCH(0);
+ADVANCE_BATCH();
+ }
}
/*
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38320] Account Request for Paul Berry
https://bugs.freedesktop.org/show_bug.cgi?id=38320 --- Comment #2 from Paul Berry 2011-06-14 15:25:07 PDT --- Created an attachment (id=47972) --> (https://bugs.freedesktop.org/attachment.cgi?id=47972) SSH key -- 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 38320] Account Request for Paul Berry
https://bugs.freedesktop.org/show_bug.cgi?id=38320 --- Comment #1 from Paul Berry 2011-06-14 15:23:37 PDT --- Created an attachment (id=47971) --> (https://bugs.freedesktop.org/attachment.cgi?id=47971) GPG key -- 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 38320] New: Account Request for Paul Berry
https://bugs.freedesktop.org/show_bug.cgi?id=38320 Summary: Account Request for Paul Berry Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: stereotype...@gmail.com I've been newly hired by Intel to work on mesa support for Intel chipsets. Requesting access to Mesa and Piglit. Name: Paul Berry Email address: stereotype...@gmail.com Preferred account name: stereotype441 -- 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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 Ian Romanick changed: What|Removed |Added CC||cwo...@cworth.org, ||jfons...@vmware.com --- Comment #6 from Ian Romanick 2011-06-14 15:19:19 PDT --- (In reply to comment #4) > > Questions: > > I don't know the answers to these questions. I'll check if the user who > reported this is interested in further debugging this and I'll make him a > build. > > From your perspective, how important are swrast bugs? I've been told that > swrast is getting replaced by other software renderers, "llvmpipe" and > "softpipe". Most of this code is used by all Mesa drivers. From one of the posts (https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c65) in the Mozilla bug, it looked like it should use the i915 driver instead of swrast anyway. An earlier post (https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c56) even suggests r600. It's a little confusing. I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could capture a trace for Mesa developers to replay... -- 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/6] configure.ac: remove redundant option --enable-gallium-egl
Removing this flag seems right to me, but always building the egl state tracker when gallium and egl is enabled not. So when --with-state-trackers is also removed, we'd need a new --with-egl-drivers=auto|gallium,dri2,glx or so. The usecase is that you could choose to use st/dri together with egl_dri2, if you dont want to have the additional pipe drivers for the egl state tracker around. Also for distributions egl_dri2 is probably the preferred driver as its the smoothest in comibination with classic intel dri drivers and gallium- vs classic-driver decisions for dri drivers (like the post-install gallium/classic switch in gentoo). I understand that the last argument may be not be valid as all classic drivers that have gallium adequates are deprected. Ben 2011/6/14 Marek Olšák : > We already have --enable-gallium, --enable-egl, and --with-state-trackers=egl. > --- > configure.ac | 30 -- > 1 files changed, 4 insertions(+), 26 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 69513c1..90171fa 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1201,6 +1201,9 @@ if test "x$enable_egl" = xyes; then > SRC_DIRS="$SRC_DIRS egl" > EGL_LIB_DEPS="$DLOPEN_LIBS $SELINUX_LIBS -lpthread" > EGL_DRIVERS_DIRS="" > + GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS egl" > + HAVE_ST_EGL="yes" > + > if test "$enable_static" != yes; then > # build egl_glx when libGL is built > if test "$mesa_driver" = xlib -o "$mesa_driver" = dri; then > @@ -1470,26 +1473,6 @@ dnl > dnl Gallium state trackers configuration > dnl > > -AC_ARG_ENABLE([gallium-egl], > - [AS_HELP_STRING([--enable-gallium-egl], > - [enable gallium EGL state tracker @<:@default=auto@:>@])], > - [enable_gallium_egl="$enableval"], > - [enable_gallium_egl=auto]) > -if test "x$enable_gallium_egl" = xauto; then > - case "$mesa_driver" in > - dri|no) > - enable_gallium_egl=$enable_egl > - ;; > - *) > - enable_gallium_egl=$enable_openvg > - ;; > - esac > -fi > -case "x$enable_egl$enable_gallium_egl" in > -xnoyes) > - AC_MSG_ERROR([cannot build Gallium EGL state tracker without EGL]) > -esac > - > AC_ARG_WITH([state-trackers], > [AS_HELP_STRING([--with-state-trackers@<:@=DIRS...@:>@], > [comma delimited state_trackers list, e.g. > @@ -1522,11 +1505,6 @@ yes) > GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS vega" > st_egl="yes" > fi > - > - if test "$enable_gallium_egl" = yes; then > - GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS egl" > - HAVE_ST_EGL="yes" > - fi > fi > ;; > *) > @@ -1577,7 +1555,7 @@ yes) > if test "x$have_st_vega" != xyes -a "x$enable_openvg" = xyes; then > AC_MSG_ERROR([--with-state-trackers specified but vega is missing]) > fi > - if test "x$HAVE_ST_EGL" != xyes -a "x$enable_gallium_egl" = xyes; then > + if test "x$HAVE_ST_EGL" != xyes; then > AC_MSG_ERROR([--with-state-trackers specified but egl is missing]) > fi > ;; > -- > 1.7.4.1 > > ___ > 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
[Mesa-dev] [Bug 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 Robert Kaiser changed: What|Removed |Added CC||ka...@kairo.at -- 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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 --- Comment #5 from Benoit Jacob 2011-06-14 13:28:02 PDT --- Also, I forgot something in my pseudocode: we call glCheckFramebufferStatus right before the glGetIntegerv call. This shouldn't make any difference, but it could hit a bug whereby glCheckFramebufferStatus resets the framebuffer binding. -- 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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 --- Comment #4 from Benoit Jacob 2011-06-14 13:17:06 PDT --- > Questions: I don't know the answers to these questions. I'll check if the user who reported this is interested in further debugging this and I'll make him a build. >From your perspective, how important are swrast bugs? I've been told that swrast is getting replaced by other software renderers, "llvmpipe" and "softpipe". -- 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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 Chad Versace changed: What|Removed |Added CC||c...@chad-versace.us -- 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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Ian Romanick changed:
What|Removed |Added
Keywords||NEEDINFO
--- Comment #3 from Ian Romanick 2011-06-14 12:45:41 PDT
---
(In reply to comment #0)
> This comes from https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c64
>
> This seems to be a swrast bug, but I didn't find the bugzilla component for
> it.
>
> I have code like this:
>
> glBindFramebuffer(...some arguments...);
> glFramebufferRenderbuffer(...some arguments...);
> GLenum error = glGetError();
> if (error != GL_NO_ERROR)
> exit(1);
> // no GL error at this point
> GLint framebuffer;
> glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &framebuffer);
> if (!framebuffer)
> printf("WTF???\n");
>
> The bug is that the WTF line is reached. Since glBindFramebuffer and
> glFramebufferRenderbuffer succeeded, for sure we have a FBO bound. So it's a
> bug that glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &result) returns 0.
Questions:
1. In the 'if (!framebuffer)' case, is there a GL error?
2. If you initialize framebuffer to, say, 0xDEADBEEF before calling
glGetIntegerv, is it still 0 after?
3. Does this still happen with more recent bits? Mesa 7.10.3 was released
yesterday.
--
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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312 --- Comment #2 from Benoit Jacob 2011-06-14 12:37:44 PDT --- ...and, in case you wonder what LOCAL_GL_FRAMEBUFFER_BINDING is, it's just the same as GL_FRAMEBUFFER_BINDING, i forgot to edit that part. It's defined as 0x8CA6 which is the correct value. -- 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 38312] Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #1 from Benoit Jacob 2011-06-14 12:35:21 PDT
---
Here's some info from the user who reported the bug to us:
OS: openSUSE Linux 11.4 (version: Final, architecture: x86_64)
Software packages (among others, of course):
xorg-x11-driver-video 7.6-53.58.1 ("intel" driver in service)
Mesa 7.10.2-7.3.1
DirectFB-Mesa 1.4.5-14.2
Hardware devices (among others, of course):
Motherboard: Intel/Fujitsu Scenic W620 (handling display, network, PCI)
Framebuffer Device: Intel(r)915G/915GV/910GL Graphics Controller
--
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] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
Hi Brian,
Please give this change a try. It should clear up the gcc -pedantic warnings
and also replaces the NULL entries with noops since that seems to be done in
other tables as well (eg: indirect_init.c).
Thanks,
Jeremy
diff --git a/src/mapi/glapi/gen/gl_gentable.py
b/src/mapi/glapi/gen/gl_gentable.py
index 73986f2..4420e3a 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -34,6 +34,10 @@ import gl_XML, glX_XML
import sys, getopt
header = """
+#if defined(DEBUG) && !defined(_WIN32_WCE)
+#include
+#endif
+
#include
#include
#include
@@ -43,6 +47,40 @@ header = """
#include "glapi.h"
#include "glapitable.h"
+static void
+__glapi_gentable_NoOp(void) {
+#if defined(DEBUG) && !defined(_WIN32_WCE)
+if (getenv("MESA_DEBUG") || getenv("LIBGL_DEBUG")) {
+const char *fstr = "Unknown";
+void *frames[2];
+
+if(backtrace(frames, 2) == 2) {
+Dl_info info;
+dladdr(frames[1], &info);
+if(info.dli_sname)
+fstr = info.dli_sname;
+}
+
+fprintf(stderr, "Call to unimplemented API: %s\\n", fstr);
+}
+#endif
+}
+
+static void
+__glapi_gentable_set_remaining_noop(struct _glapi_table *disp) {
+GLuint entries = _glapi_get_dispatch_table_size();
+void **dispatch = (void **) disp;
+int i;
+
+/* ISO C is annoying sometimes */
+union {_glapi_proc p; void *v;} p;
+p.p = __glapi_gentable_NoOp;
+
+for(i=0; i < entries; i++)
+if(dispatch[i] == NULL)
+dispatch[i] = p.v;
+}
+
struct _glapi_table *
_glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
struct _glapi_table *disp = calloc(1, sizeof(struct _glapi_table));
@@ -56,6 +94,8 @@ _glapi_create_table_from_handle(void *handle, const char
*symbol_prefix) {
"""
footer = """
+__glapi_gentable_set_remaining_noop(disp);
+
return disp;
}
"""
@@ -63,8 +103,8 @@ footer = """
body_template = """
if(!disp->%(name)s) {
snprintf(symboln, sizeof(symboln), "%%s%(entry_point)s",
symbol_prefix);
-_glapi_proc *procp = (_glapi_proc *)&disp->%(name)s;
-*procp = (_glapi_proc) dlsym(handle, symboln);
+void ** procp = (void **) &disp->%(name)s;
+*procp = dlsym(handle, symboln);
}
"""
On Jun 13, 2011, at 3:13 PM, Brian Paul wrote:
> On 06/13/2011 03:53 PM, Jeremy Huddleston wrote:
>> b44d13e67bfe81b2d7af4aeda2c3caf7f252bd0f should work for you. Thanks for
>> letting me know.
>
> Another warning:
>
>
> glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
> glapi_gentable.c:54:9: warning: ISO C90 forbids mixed declarations and code
> glapi_gentable.c:55:18: warning: ISO C forbids conversion of object pointer
> to f
> unction pointer type
> glapi_gentable.c:61:9: warning: ISO C90 forbids mixed declarations and code
> glapi_gentable.c:62:18: warning: ISO C forbids conversion of object pointer
> to f
> unction pointer type
> glapi_gentable.c:68:9: warning: ISO C90 forbids mixed declarations and code
> glapi_gentable.c:69:18: warning: ISO C forbids conversion of object pointer
> to f
> unction pointer type
>
>
> Need to put the _glapi_proc declaration first.
>
> -Brian
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38312] New: Swrast doesn't really know whether a Framebuffer object is bound
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Summary: Swrast doesn't really know whether a Framebuffer
object is bound
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: bja...@mozilla.com
This comes from https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c64
This seems to be a swrast bug, but I didn't find the bugzilla component for it.
I have code like this:
glBindFramebuffer(...some arguments...);
glFramebufferRenderbuffer(...some arguments...);
GLenum error = glGetError();
if (error != GL_NO_ERROR)
exit(1);
// no GL error at this point
GLint framebuffer;
glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &framebuffer);
if (!framebuffer)
printf("WTF???\n");
The bug is that the WTF line is reached. Since glBindFramebuffer and
glFramebufferRenderbuffer succeeded, for sure we have a FBO bound. So it's a
bug that glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &result) returns 0.
This is only confirmed with the swrast driver.
--
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 v4] linker: Reject shaders that use too many varyings
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743
---
v4: I'm done.
src/glsl/linker.cpp | 41 -
1 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 255edc6..b6479e7 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1405,8 +1405,9 @@ demote_shader_inputs_and_outputs(gl_shader *sh, enum
ir_variable_mode mode)
}
-void
-assign_varying_locations(struct gl_shader_program *prog,
+bool
+assign_varying_locations(struct gl_context *ctx,
+struct gl_shader_program *prog,
gl_shader *producer, gl_shader *consumer)
{
/* FINISHME: Set dynamically when geometry shader support is added. */
@@ -1462,6 +1463,8 @@ assign_varying_locations(struct gl_shader_program *prog,
}
}
+ unsigned varying_vectors = 0;
+
foreach_list(node, consumer->ir) {
ir_variable *const var = ((ir_instruction *) node)->as_variable();
@@ -1492,8 +1495,32 @@ assign_varying_locations(struct gl_shader_program *prog,
* value is written by the previous stage.
*/
var->mode = ir_var_auto;
+ } else {
+/* The packing rules are used for vertex shader inputs are also used
+ * for fragment shader inputs.
+ */
+varying_vectors += count_attribute_slots(var->type);
}
}
+
+ if (ctx->API == API_OPENGLES2 || prog->Version == 100) {
+ if (varying_vectors > ctx->Const.MaxVarying) {
+linker_error_printf(prog, "shader uses too many varying vectors "
+"(%u > %u)\n",
+varying_vectors, ctx->Const.MaxVarying);
+return false;
+ }
+ } else {
+ const unsigned float_components = varying_vectors * 4;
+ if (float_components > ctx->Const.MaxVarying * 4) {
+linker_error_printf(prog, "shader uses too many varying components "
+"(%u > %u)\n",
+float_components, ctx->Const.MaxVarying * 4);
+return false;
+ }
+ }
+
+ return true;
}
@@ -1666,9 +1693,13 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
if (prog->_LinkedShaders[i] == NULL)
continue;
- assign_varying_locations(prog,
- prog->_LinkedShaders[prev],
- prog->_LinkedShaders[i]);
+ if (!assign_varying_locations(ctx, prog,
+ prog->_LinkedShaders[prev],
+ prog->_LinkedShaders[i])) {
+prog->LinkStatus = false;
+goto done;
+ }
+
prev = i;
}
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] linker: Reject shaders that use too many varyings
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743
---
v2: My previous recollection of the GLSL spec was incorrect. The same
input packing rule of one slot per variable float or vector is used
for both vertex inputs and fragment inputs. This also removes the
stray debug printf.
v3: Same as v2, but less Palin.
src/glsl/linker.cpp | 41 -
1 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 255edc6..9b3d189 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1405,8 +1405,9 @@ demote_shader_inputs_and_outputs(gl_shader *sh, enum
ir_variable_mode mode)
}
-void
-assign_varying_locations(struct gl_shader_program *prog,
+bool
+assign_varying_locations(struct gl_context *ctx,
+struct gl_shader_program *prog,
gl_shader *producer, gl_shader *consumer)
{
/* FINISHME: Set dynamically when geometry shader support is added. */
@@ -1462,6 +1463,8 @@ assign_varying_locations(struct gl_shader_program *prog,
}
}
+ unsigned float_components = 0;
+
foreach_list(node, consumer->ir) {
ir_variable *const var = ((ir_instruction *) node)->as_variable();
@@ -1492,8 +1495,32 @@ assign_varying_locations(struct gl_shader_program *prog,
* value is written by the previous stage.
*/
var->mode = ir_var_auto;
+ } else {
+/* The packing rules are used for vertex shader inputs are also used
+ * for fragment shader inputs.
+ */
+varying_vectors += count_attribute_slots(var->type);
}
}
+
+ if (ctx->API == API_OPENGLES2 || prog->Version == 100) {
+ if (varying_vectors > ctx->Const.MaxVarying) {
+linker_error_printf(prog, "shader uses too many varying vectors "
+"(%u > %u)\n",
+varying_vectors, ctx->Const.MaxVarying);
+return false;
+ }
+ } else {
+ const unsigned float_components = varying_vectors * 4;
+ if (float_components > ctx->Const.MaxVarying * 4) {
+linker_error_printf(prog, "shader uses too many varying components "
+"(%u > %u)\n",
+float_components, ctx->Const.MaxVarying * 4);
+return false;
+ }
+ }
+
+ return true;
}
@@ -1666,9 +1693,13 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
if (prog->_LinkedShaders[i] == NULL)
continue;
- assign_varying_locations(prog,
- prog->_LinkedShaders[prev],
- prog->_LinkedShaders[i]);
+ if (!assign_varying_locations(ctx, prog,
+ prog->_LinkedShaders[prev],
+ prog->_LinkedShaders[i])) {
+prog->LinkStatus = false;
+goto done;
+ }
+
prev = i;
}
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] linker: Reject shaders that use too many varyings
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743
---
v2: My previous recollection of the GLSL spec was incorrect. The same
input packing rule of one slot per variable float or vector is used
for both vertex inputs and fragment inputs. This also removes the
stray debug printf.
src/glsl/linker.cpp | 41 -
1 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 255edc6..9b3d189 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1405,8 +1405,9 @@ demote_shader_inputs_and_outputs(gl_shader *sh, enum
ir_variable_mode mode)
}
-void
-assign_varying_locations(struct gl_shader_program *prog,
+bool
+assign_varying_locations(struct gl_context *ctx,
+struct gl_shader_program *prog,
gl_shader *producer, gl_shader *consumer)
{
/* FINISHME: Set dynamically when geometry shader support is added. */
@@ -1462,6 +1463,8 @@ assign_varying_locations(struct gl_shader_program *prog,
}
}
+ unsigned float_components = 0;
+
foreach_list(node, consumer->ir) {
ir_variable *const var = ((ir_instruction *) node)->as_variable();
@@ -1492,8 +1495,32 @@ assign_varying_locations(struct gl_shader_program *prog,
* value is written by the previous stage.
*/
var->mode = ir_var_auto;
+ } else {
+/* The packing rules are used for vertex shader inputs are also used
+ * for fragment shader inputs.
+ */
+varying_vectors += count_attribute_slots(var->type);
}
}
+
+ if (ctx->API == API_OPENGLES2 || prog->Version == 100) {
+ if (varying_vectors > ctx->Const.MaxVarying) {
+linker_error_printf(prog, "shader uses too many varying vectors "
+"(%u > %u)\n",
+varying_vectors, ctx->Const.MaxVarying);
+return false;
+ }
+ } else {
+ const unsigned float_components = varying_vectors * 4;
+ if (float_components > ctx->Const.MaxVarying * 4) {
+linker_error_printf(prog, "shader uses too many varying components "
+"(%u > %u)\n",
+float_components, ctx->Const.MaxVarying * 4);
+return false;
+ }
+ }
+
+ return true;
}
@@ -1666,9 +1693,13 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
if (prog->_LinkedShaders[i] == NULL)
continue;
- assign_varying_locations(prog,
- prog->_LinkedShaders[prev],
- prog->_LinkedShaders[i]);
+ if (!assign_varying_locations(ctx, prog,
+ prog->_LinkedShaders[prev],
+ prog->_LinkedShaders[i])) {
+prog->LinkStatus = false;
+goto done;
+ }
+
prev = i;
}
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenGL compositors and glxWaitX()
On Die, 2011-06-07 at 10:17 +0200, Thomas Hellstrom wrote: > On 06/06/2011 05:20 PM, James Jones wrote: > > On 6/6/11 2:09 AM, "Thomas Hellstrom" wrote: > > > > > >> Hi! > >> > >> While trying to improve the vmwgfx X driver to better cope with OpenGL > >> compositors, I noticed that compiz never calls glxWaitX() to make sure > >> the pixmaps that it textures from are updated. > >> > >> Since we migrate X rendered data to the dri2 drawables only on demand, > >> we miss a lot of data. > >> > >> Googling for this it seems this has been up for discussion before, and > >> it appears glxWaitX() is not used because either > >> > >> 1) it's considered to be a performance hit. > >> 2) it only affects the drawables currently bound by the glx context > >> issuing the command. > >> > >> While 1) may be true, > >> > > A properly implemented glXWaitX shouldn't cause much if any noticeable > > performance hit. However, I don't know how optimal existing implementations > > are. > > > > Well, something must tell X to flush its rendering buffers and (in the > direct rendering case) wait until the X server notifies that it has done > so. So there is at least an X server roundtrip and a corresponding > client stall, which would degrade client performance if it is CPU bound. > > > > >> reading the glx specification it appears to me > >> that 2) does not hold, even if it appears like some dri2 server side > >> implementations do not flush all drawables. Furthermore it appears to me > >> to be a requirement for correctness to call glXWaitX before using the > >> pixmap content. > >> > >> Does anyone on the list have more info on this, and whether not calling > >> glxWaitX() is the common usage pattern by other compositors? > >> > > 2) is not quite true, but glXWaitX is still not sufficient. glXWaitX only > > waits for rendering done on the specified display to complete. When using > > composite managers, all the rendering you want to wait for in the composite > > manager happens on other display connections (the client apps). glXWaitX is > > specified to, at best, be equivalent to XSync(). > > > > I've been told DRI2 based drivers implicitly synchronize texture from pixmap > > operations with X rendering > > I'm not sure how that will happen, unless the X driver flushes all > rendering immediately or at least when the server executes > DamageProcessPending() following the rendering operation. If I'm not > missing something, a driver that relies on, for example, a block handler > or glXWaitX to migrate software rendered stuff to the dri2 drawable will > fail. The major DRI2 drivers achieve this by flushing rendering to the hardware in a FlushCallback, which is called before events are sent to clients (so it always happens before the compositing manager gets the damage events). The Gallium xorg state tracker could probably do something like that as well. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Overhaul of Gallium configure options
On Die, 2011-06-14 at 09:45 -0700, Jose Fonseca wrote: > > - Original Message - > > On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote: > > > Hi, > > > > > > This series reworks some of our configure options to make Gallium > > > easier to configure. > > > > > > First, there is a new option --with-gallium-drivers=DIRS, which > > > replaces the current heap of options --enable-gallium-DRIVER. > > > --disable-gallium is removed as well, instead, > > > --with-gallium-drivers= without parameters should be used to > > > disable Gallium. > > > > > > --enable-gallium-egl is removed. having --enable-egl and > > > --with-gallium-drivers=somedriver is sufficient. > > > > > > --with-state-trackers is removed as well. The list of state > > > trackers is automatically deduced from the --enable-API options > > > (the vega,egl state trackers) and --with-driver=dri|xlib (the > > > dri,glx state trackers). Some state trackers lack an enable flag > > > now, so these two have been added to make the list complete: > > > --enable-xorg and --enable-d3d1x. > > > > > > In order to be able to "git bisect run" through this change, you > > > can specify both the old and new options at the same time. Those > > > that are unsupported are ignored. > > > > > > Other than that, I am enabling r600g by default and removing r300g > > > and r600g from scons. I am not a fan of having multiple build > > > systems and most people prefer autoconf anyway. It's not like > > > anybody needs to build those drivers on Windows. > > > > I did use r600g + scons for the little bit of work I did there, and > > if I > > went back to it, it would continue to be with scons... > > > > Is there a significant cost to you having it there? > > > > Keith > > Ditto. I've been building r600g on linux with scons too -- scons it's > much better for continuous integration/testing, given one doesn't need > to do make clean everytime, just to ensure the dependencies are > computed correctly. > > Given that autoconf will never support MSVC, if people don't like > multiple build systems, then autoconf+gmake is definely not the one to > bet on. > > I've been (slowly) trying to get scons to build everything, and plan > to do so. So that scons can be a viable alternative eventually. That would certainly seem like a better solution. As another example, scons is currently the only useful way to build 32 and 64 bit binaries from a single tree. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37274] Crash in draw_llvm_shader23 (r300g, rs690, in warzone2100)
https://bugs.freedesktop.org/show_bug.cgi?id=37274 --- Comment #5 from okias 2011-06-14 10:41:48 PDT --- ~ $ GALLIUM_DUMP_CPU=1 glxgears util_cpu_caps.nr_cpus = 2 util_cpu_caps.x86_cpu_type = 8 util_cpu_caps.cacheline = 64 util_cpu_caps.has_tsc = 1 util_cpu_caps.has_mmx = 1 util_cpu_caps.has_mmx2 = 1 util_cpu_caps.has_sse = 1 util_cpu_caps.has_sse2 = 1 util_cpu_caps.has_sse3 = 1 util_cpu_caps.has_ssse3 = 0 util_cpu_caps.has_sse4_1 = 0 util_cpu_caps.has_sse4_2 = 0 util_cpu_caps.has_avx = 0 util_cpu_caps.has_3dnow = 1 util_cpu_caps.has_3dnow_ext = 1 util_cpu_caps.has_altivec = 0 r300: DRM version: 2.10.0, Name: ATI RS690, ID: 0x791f, GB: 1, Z: 1 r300: GART size: 509 MB, VRAM size: 128 MB r300: AA compression RAM: YES, Z compression RAM: NO, HiZ RAM: NO Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. ^C -- 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 0/6] Overhaul of Gallium configure options
- Original Message - > On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote: > > Hi, > > > > This series reworks some of our configure options to make Gallium > > easier to configure. > > > > First, there is a new option --with-gallium-drivers=DIRS, which > > replaces the current heap of options --enable-gallium-DRIVER. > > --disable-gallium is removed as well, instead, > > --with-gallium-drivers= without parameters should be used to > > disable Gallium. > > > > --enable-gallium-egl is removed. having --enable-egl and > > --with-gallium-drivers=somedriver is sufficient. > > > > --with-state-trackers is removed as well. The list of state > > trackers is automatically deduced from the --enable-API options > > (the vega,egl state trackers) and --with-driver=dri|xlib (the > > dri,glx state trackers). Some state trackers lack an enable flag > > now, so these two have been added to make the list complete: > > --enable-xorg and --enable-d3d1x. > > > > In order to be able to "git bisect run" through this change, you > > can specify both the old and new options at the same time. Those > > that are unsupported are ignored. > > > > Other than that, I am enabling r600g by default and removing r300g > > and r600g from scons. I am not a fan of having multiple build > > systems and most people prefer autoconf anyway. It's not like > > anybody needs to build those drivers on Windows. > > I did use r600g + scons for the little bit of work I did there, and > if I > went back to it, it would continue to be with scons... > > Is there a significant cost to you having it there? > > Keith Ditto. I've been building r600g on linux with scons too -- scons it's much better for continuous integration/testing, given one doesn't need to do make clean everytime, just to ensure the dependencies are computed correctly. Given that autoconf will never support MSVC, if people don't like multiple build systems, then autoconf+gmake is definely not the one to bet on. I've been (slowly) trying to get scons to build everything, and plan to do so. So that scons can be a viable alternative eventually. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Overhaul of Gallium configure options
On Tue, Jun 14, 2011 at 12:25 PM, Marek Olšák wrote: > Hi, > > This series reworks some of our configure options to make Gallium easier to > configure. > > First, there is a new option --with-gallium-drivers=DIRS, which replaces the > current heap of options --enable-gallium-DRIVER. --disable-gallium is removed > as well, instead, --with-gallium-drivers= without parameters should be used > to disable Gallium. > > --enable-gallium-egl is removed. having --enable-egl and > --with-gallium-drivers=somedriver is sufficient. > > --with-state-trackers is removed as well. The list of state trackers is > automatically deduced from the --enable-API options (the vega,egl state > trackers) and --with-driver=dri|xlib (the dri,glx state trackers). Some state > trackers lack an enable flag now, so these two have been added to make the > list complete: --enable-xorg and --enable-d3d1x. > > In order to be able to "git bisect run" through this change, you can specify > both the old and new options at the same time. Those that are unsupported are > ignored. > > Other than that, I am enabling r600g by default and removing r300g and r600g > from scons. I am not a fan of having multiple build systems and most people > prefer autoconf anyway. It's not like anybody needs to build those drivers on > Windows. > > Please review. Patches look good to me. Reviewed-by: Alex Deucher > > BTW, one issue remains: > In order to build a Gallium EGL driver, st/dri or st/xorg must be enabled (so > that the driver's winsys dir is included), even though EGL and its APIs are > an entirely separate project. configure.ac has no control over it. The EGL > drivers are hardcoded in src/gallium/targets/egl and are compiled if their > winsyses are compiled as well. > > Marek Olšák (6): > configure.ac: remove redundant option --enable-gallium-egl > configure.ac: remove --with-state-trackers > configure.ac: add option --with-gallium-drivers=DIRS > configure.ac: build r600g by default > scons: remove r300g from the build system > scons: remove r600g from the build system > > Makefile | 1 - > configure.ac | 394 > - > src/gallium/SConscript | 14 +- > src/gallium/drivers/r300/SConscript | 44 --- > src/gallium/drivers/r600/SConscript | 37 --- > src/gallium/targets/dri-r300/SConscript | 26 -- > src/gallium/targets/dri-r600/SConscript | 25 -- > src/gallium/targets/egl-static/SConscript | 9 - > src/gallium/winsys/SConscript | 8 - > src/gallium/winsys/r600/drm/SConscript | 29 -- > src/gallium/winsys/radeon/drm/SConscript | 22 -- > src/mesa/drivers/dri/r300/compiler/SConscript | 51 > 12 files changed, 128 insertions(+), 532 deletions(-) > delete mode 100644 src/gallium/drivers/r300/SConscript > delete mode 100644 src/gallium/drivers/r600/SConscript > delete mode 100644 src/gallium/targets/dri-r300/SConscript > delete mode 100644 src/gallium/targets/dri-r600/SConscript > delete mode 100644 src/gallium/winsys/r600/drm/SConscript > delete mode 100644 src/gallium/winsys/radeon/drm/SConscript > delete mode 100755 src/mesa/drivers/dri/r300/compiler/SConscript > > Best regards > Marek > ___ > 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
[Mesa-dev] [PATCH 4/6] configure.ac: build r600g by default
--- configure.ac |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 804b8a7..b2a0f66 100644 --- a/configure.ac +++ b/configure.ac @@ -550,13 +550,13 @@ AC_ARG_ENABLE([egl], [enable_egl=yes]) # Option for Gallium drivers -GALLIUM_DRIVERS_DEFAULT="r300,swrast" +GALLIUM_DRIVERS_DEFAULT="r300,r600,swrast" AC_ARG_WITH([gallium-drivers], [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@], [comma delimited Gallium drivers list, e.g. "i915,i965,nouveau,r300,r600,svga,swrast" -@<:@default=r300,swrast@:>@])], +@<:@default=r300,r600,swrast@:>@])], [with_gallium_drivers="$withval"], [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"]) -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Overhaul of Gallium configure options
On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote: > Hi, > > This series reworks some of our configure options to make Gallium easier to > configure. > > First, there is a new option --with-gallium-drivers=DIRS, which replaces the > current heap of options --enable-gallium-DRIVER. --disable-gallium is removed > as well, instead, --with-gallium-drivers= without parameters should be used > to disable Gallium. > > --enable-gallium-egl is removed. having --enable-egl and > --with-gallium-drivers=somedriver is sufficient. > > --with-state-trackers is removed as well. The list of state trackers is > automatically deduced from the --enable-API options (the vega,egl state > trackers) and --with-driver=dri|xlib (the dri,glx state trackers). Some state > trackers lack an enable flag now, so these two have been added to make the > list complete: --enable-xorg and --enable-d3d1x. > > In order to be able to "git bisect run" through this change, you can specify > both the old and new options at the same time. Those that are unsupported are > ignored. > > Other than that, I am enabling r600g by default and removing r300g and r600g > from scons. I am not a fan of having multiple build systems and most people > prefer autoconf anyway. It's not like anybody needs to build those drivers on > Windows. I did use r600g + scons for the little bit of work I did there, and if I went back to it, it would continue to be with scons... Is there a significant cost to you having it there? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] configure.ac: remove redundant option --enable-gallium-egl
We already have --enable-gallium, --enable-egl, and --with-state-trackers=egl. --- configure.ac | 30 -- 1 files changed, 4 insertions(+), 26 deletions(-) diff --git a/configure.ac b/configure.ac index 69513c1..90171fa 100644 --- a/configure.ac +++ b/configure.ac @@ -1201,6 +1201,9 @@ if test "x$enable_egl" = xyes; then SRC_DIRS="$SRC_DIRS egl" EGL_LIB_DEPS="$DLOPEN_LIBS $SELINUX_LIBS -lpthread" EGL_DRIVERS_DIRS="" +GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS egl" +HAVE_ST_EGL="yes" + if test "$enable_static" != yes; then # build egl_glx when libGL is built if test "$mesa_driver" = xlib -o "$mesa_driver" = dri; then @@ -1470,26 +1473,6 @@ dnl dnl Gallium state trackers configuration dnl -AC_ARG_ENABLE([gallium-egl], -[AS_HELP_STRING([--enable-gallium-egl], -[enable gallium EGL state tracker @<:@default=auto@:>@])], -[enable_gallium_egl="$enableval"], -[enable_gallium_egl=auto]) -if test "x$enable_gallium_egl" = xauto; then -case "$mesa_driver" in -dri|no) -enable_gallium_egl=$enable_egl -;; -*) -enable_gallium_egl=$enable_openvg -;; -esac -fi -case "x$enable_egl$enable_gallium_egl" in -xnoyes) -AC_MSG_ERROR([cannot build Gallium EGL state tracker without EGL]) -esac - AC_ARG_WITH([state-trackers], [AS_HELP_STRING([--with-state-trackers@<:@=DIRS...@:>@], [comma delimited state_trackers list, e.g. @@ -1522,11 +1505,6 @@ yes) GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS vega" st_egl="yes" fi - -if test "$enable_gallium_egl" = yes; then -GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS egl" -HAVE_ST_EGL="yes" -fi fi ;; *) @@ -1577,7 +1555,7 @@ yes) if test "x$have_st_vega" != xyes -a "x$enable_openvg" = xyes; then AC_MSG_ERROR([--with-state-trackers specified but vega is missing]) fi -if test "x$HAVE_ST_EGL" != xyes -a "x$enable_gallium_egl" = xyes; then +if test "x$HAVE_ST_EGL" != xyes; then AC_MSG_ERROR([--with-state-trackers specified but egl is missing]) fi ;; -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] configure.ac: remove --with-state-trackers
There is an obvious redundancy: --with-driver=dri VS --with-state-trackers=dri --with-driver=xlib VS --with-state-trackers=glx --enable-openvg VS --with-state-trackers=vega --enable-egl VS --with-state-trackers=egl This patch adds two new options for the remaining state trackers: --enable-xorg --enable-d3d1x --- configure.ac | 217 -- 1 files changed, 75 insertions(+), 142 deletions(-) diff --git a/configure.ac b/configure.ac index 90171fa..5d045f0 100644 --- a/configure.ac +++ b/configure.ac @@ -507,7 +507,7 @@ if test "x$enable_selinux" = "xyes"; then DEFINES="$DEFINES -DMESA_SELINUX" fi -dnl Determine which APIs to support +dnl Options for APIs AC_ARG_ENABLE([opengl], [AS_HELP_STRING([--disable-opengl], [disable support for standard OpenGL API @<:@default=no@:>@])], @@ -528,27 +528,40 @@ AC_ARG_ENABLE([gles-overlay], [DEPRECATED. Same as --enable-gles1 and --enable-gles2])], [enable_gles1="$enableval"; enable_gles2="$enableval"], []) - AC_ARG_ENABLE([openvg], [AS_HELP_STRING([--enable-openvg], [enable support for OpenVG API @<:@default=no@:>@])], [enable_openvg="$enableval"], [enable_openvg=no]) +AC_ARG_ENABLE([xorg], +[AS_HELP_STRING([--enable-xorg], +[enable support for X.Org DDX API @<:@default=no@:>@])], +[enable_xorg="$enableval"], +[enable_xorg=no]) +AC_ARG_ENABLE([d3d1x], +[AS_HELP_STRING([--enable-d3d1x], +[enable support for Direct3D 10 & 11 low-level API @<:@default=no@:>@])], +[enable_d3d1x="$enableval"], +[enable_d3d1x=no]) +AC_ARG_ENABLE([egl], +[AS_HELP_STRING([--disable-egl], +[disable EGL library @<:@default=enabled@:>@])], +[enable_egl="$enableval"], +[enable_egl=yes]) -dnl smooth the transition; should be removed eventually -if test "x$enable_openvg" = xno; then -case "x$with_state_trackers" in -x*vega*) -AC_MSG_WARN([vega state tracker is enabled without --enable-openvg]) -enable_openvg=yes -;; -esac -fi +# Option for Gallium +AC_ARG_ENABLE([gallium], +[AS_HELP_STRING([--disable-gallium], +[build gallium @<:@default=enabled@:>@])], +[enable_gallium="$enableval"], +[enable_gallium=yes]) if test "x$enable_opengl" = xno -a \ "x$enable_gles1" = xno -a \ "x$enable_gles2" = xno -a \ -"x$enable_openvg" = xno; then +"x$enable_openvg" = xno -a \ +"x$enable_xorg" = xno -a \ +"x$enable_d3d1x" = xno; then AC_MSG_ERROR([at least one API should be enabled]) fi @@ -657,11 +670,6 @@ if test "x$enable_gles2" = xyes; then CORE_DIRS="$CORE_DIRS mapi/es2api" fi -# build vgapi if OpenVG is enabled -if test "x$enable_openvg" = xyes; then -CORE_DIRS="$CORE_DIRS mapi/vgapi" -fi - # build glsl and mesa if OpenGL or OpenGL ES is enabled case "x$enable_opengl$enable_gles1$enable_gles2" in x*yes*) @@ -674,11 +682,14 @@ xlib) DRIVER_DIRS="x11" GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib" GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS libgl-xlib" +GALLIUM_STATE_TRACKERS_DIRS="glx $GALLIUM_STATE_TRACKERS_DIRS" ;; dri) SRC_DIRS="$SRC_DIRS glx" DRIVER_DIRS="dri" GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib sw/dri" +GALLIUM_STATE_TRACKERS_DIRS="dri $GALLIUM_STATE_TRACKERS_DIRS" +HAVE_ST_DRI="yes" ;; osmesa) DRIVER_DIRS="osmesa" @@ -1184,24 +1195,19 @@ AC_SUBST([OSMESA_PC_LIB_PRIV]) dnl dnl EGL configuration dnl -AC_ARG_ENABLE([egl], -[AS_HELP_STRING([--disable-egl], -[disable EGL library @<:@default=enabled@:>@])], -[enable_egl="$enableval"], -[enable_egl=yes]) +EGL_CLIENT_APIS="" + if test "x$enable_egl" = xno; then if test "x$mesa_driver" = xno; then AC_MSG_ERROR([cannot disable EGL when there is no mesa driver]) fi -if test "x$enable_openvg" = xyes; then -AC_MSG_ERROR([cannot enable OpenVG without EGL]) -fi fi if test "x$enable_egl" = xyes; then SRC_DIRS="$SRC_DIRS egl" EGL_LIB_DEPS="$DLOPEN_LIBS $SELINUX_LIBS -lpthread" EGL_DRIVERS_DIRS="" -GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS egl" +GALLIUM_STATE_TRACKERS_DIRS="egl $GALLIUM_STATE_TRACKERS_DIRS" +GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS egl" HAVE_ST_EGL="yes" if test "$enable_static" != yes; then @@ -1236,6 +1242,49 @@ AC_SUBST([EGL_LIB_DEPS]) AC_SUBST([EGL_DRIVERS_DIRS]) dnl +dnl X.Org DDX configuration +dnl +if test "x$enable_xorg" = xyes; then +PKG_CHECK_MODULES([XORG], [xorg-server >= 1.6.0]) +PKG_CHECK_MODULES([LIBDRM_XORG], [libdrm >= $LIBDRM_XORG_REQUIRED]) +PKG_CHECK_MODULES([LIBKMS_XORG], [libkms >= $LIBKMS_XORG_REQUIRED]) +PKG_CHECK_MODULES(XEXT, [xextproto >= 7.0.99.1], +HAVE_XEXTPROTO_71="yes"; DEFINES="$DEFINES -DHAVE_XEXTPROTO_71", +HAVE_XEXTPROTO_71="no") +GALLIUM_STATE_TRACKERS_DIRS="xorg $GALLIUM_STATE_TRACK
[Mesa-dev] [PATCH 6/6] scons: remove r600g from the build system
---
src/gallium/SConscript| 11 +
src/gallium/drivers/r600/SConscript | 37 -
src/gallium/targets/dri-r600/SConscript | 25 ---
src/gallium/targets/egl-static/SConscript |7 -
src/gallium/winsys/SConscript |4 ---
src/gallium/winsys/r600/drm/SConscript| 29 --
6 files changed, 1 insertions(+), 112 deletions(-)
delete mode 100644 src/gallium/drivers/r600/SConscript
delete mode 100644 src/gallium/targets/dri-r600/SConscript
delete mode 100644 src/gallium/winsys/r600/drm/SConscript
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index 4704dcd..57d2b4e 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -28,12 +28,7 @@ if not env['msvc']:
'drivers/i965/SConscript',
])
-if env['drm']:
-# These drivers depend on drm headers
-if env['drm_radeon']:
-SConscript([
-'drivers/r600/SConscript',
-])
+#if env['drm']:
# XXX: nouveau drivers have a tight dependency on libdrm, so to enable
# we need some version logic before we enable them. Also, ATM there is
# no nouveau target in scons
@@ -111,10 +106,6 @@ if env['dri']:
'targets/dri-i915/SConscript',
'targets/dri-i965/SConscript',
])
-if env['drm_radeon']:
-SConscript([
-'targets/dri-r600/SConscript',
-])
if env['xorg'] and env['drm']:
SConscript([
diff --git a/src/gallium/drivers/r600/SConscript
b/src/gallium/drivers/r600/SConscript
deleted file mode 100644
index 0135808..000
--- a/src/gallium/drivers/r600/SConscript
+++ /dev/null
@@ -1,37 +0,0 @@
-Import('*')
-
-env = env.Clone()
-
-try:
-env.ParseConfig('pkg-config --cflags libdrm_radeon')
-except OSError:
-print 'warning: not building r600'
-Return()
-
-env.Append(CPPPATH = [
-'#/include',
-'#/src/mesa',
-])
-
-r600 = env.ConvenienceLibrary(
-target = 'r600',
-source = [
-'r600_asm.c',
-'r600_buffer.c',
-'r600_blit.c',
-'r600_pipe.c',
-'r600_query.c',
-'r600_resource.c',
-'r600_shader.c',
-'r600_state.c',
-'r600_state_common.c',
-'r600_texture.c',
-'r600_translate.c',
-'r700_asm.c',
-'evergreen_state.c',
-'eg_asm.c',
-])
-
-env.Alias('r600', r600)
-
-Export('r600')
diff --git a/src/gallium/targets/dri-r600/SConscript
b/src/gallium/targets/dri-r600/SConscript
deleted file mode 100644
index 1df11a8..000
--- a/src/gallium/targets/dri-r600/SConscript
+++ /dev/null
@@ -1,25 +0,0 @@
-Import('*')
-
-env = drienv.Clone()
-
-env.Append(CPPDEFINES = ['GALLIUM_RBUG', 'GALLIUM_TRACE'])
-
-env.Prepend(LIBS = [
-st_dri,
-r600winsys,
-r600,
-trace,
-rbug,
-mesa,
-glsl,
-gallium,
-COMMON_DRI_DRM_OBJECTS
-])
-
-module = env.SharedLibrary(
-target ='r600_dri.so',
-source = 'target.c',
-SHLIBPREFIX = '',
-)
-
-env.Alias('dri-r600', module)
diff --git a/src/gallium/targets/egl-static/SConscript
b/src/gallium/targets/egl-static/SConscript
index 3adc60b..2c236ab 100644
--- a/src/gallium/targets/egl-static/SConscript
+++ b/src/gallium/targets/egl-static/SConscript
@@ -103,13 +103,6 @@ if env['drm']:
ws_wrapper,
])
-if env['drm_radeon']:
-env.Append(CPPDEFINES = ['_EGL_PIPE_R600'])
-env.Prepend(LIBS = [
-r600winsys,
-r600,
-])
-
env.Append(CPPDEFINES = ['_EGL_PIPE_VMWGFX'])
env.Prepend(LIBS = [
svgadrm,
diff --git a/src/gallium/winsys/SConscript b/src/gallium/winsys/SConscript
index 986590b..edfa842 100644
--- a/src/gallium/winsys/SConscript
+++ b/src/gallium/winsys/SConscript
@@ -33,7 +33,3 @@ if env['dri']:
SConscript([
'i965/drm/SConscript',
])
-
-SConscript([
-'r600/drm/SConscript',
-])
diff --git a/src/gallium/winsys/r600/drm/SConscript
b/src/gallium/winsys/r600/drm/SConscript
deleted file mode 100644
index cc9a06a..000
--- a/src/gallium/winsys/r600/drm/SConscript
+++ /dev/null
@@ -1,29 +0,0 @@
-Import('*')
-
-env = env.Clone()
-
-r600_sources = [
-'bof.c',
-'evergreen_hw_context.c',
-'radeon_bo.c',
-'radeon_pciid.c',
-'r600_bo.c',
-'r600_drm.c',
-'r600_hw_context.c',
-'r600_bomgr.c',
-]
-
-try:
-env.ParseConfig('pkg-config --cflags libdrm_radeon')
-except OSError:
-print 'warning: not building r600g'
-Return()
-
-env.Append(CPPPATH = '#/src/gallium/drivers/r600')
-
-r600winsys = env.ConvenienceLibrary(
-target ='r600winsys',
-source = r600_sources,
-)
-
-Export('r600winsys')
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] scons: remove r300g from the build system
It's not like anybody needs to build that on Windows.
---
Makefile |1 -
src/gallium/SConscript|3 -
src/gallium/drivers/r300/SConscript | 44 -
src/gallium/targets/dri-r300/SConscript | 26 -
src/gallium/targets/egl-static/SConscript |4 +-
src/gallium/winsys/SConscript |4 --
src/gallium/winsys/radeon/drm/SConscript | 22 ---
src/mesa/drivers/dri/r300/compiler/SConscript | 51 -
8 files changed, 1 insertions(+), 154 deletions(-)
delete mode 100644 src/gallium/drivers/r300/SConscript
delete mode 100644 src/gallium/targets/dri-r300/SConscript
delete mode 100644 src/gallium/winsys/radeon/drm/SConscript
delete mode 100755 src/mesa/drivers/dri/r300/compiler/SConscript
diff --git a/Makefile b/Makefile
index 07ec686..bddfd5d 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,6 @@ MAIN_FILES = \
$(DIRECTORY)/src/mesa/drivers/osmesa/*.[ch] \
$(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/*.[ch] \
$(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/Makefile\
- $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/SConscript \
$(DIRECTORY)/src/mesa/drivers/windows/*/*.[ch] \
$(DIRECTORY)/src/mesa/drivers/windows/*/*.def \
$(DIRECTORY)/src/mesa/drivers/x11/Makefile \
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index 428bc31..4704dcd 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -26,7 +26,6 @@ if not env['msvc']:
SConscript([
'drivers/i915/SConscript',
'drivers/i965/SConscript',
-'drivers/r300/SConscript',
])
if env['drm']:
@@ -114,7 +113,6 @@ if env['dri']:
])
if env['drm_radeon']:
SConscript([
-'targets/dri-r300/SConscript',
'targets/dri-r600/SConscript',
])
@@ -123,7 +121,6 @@ if env['xorg'] and env['drm']:
#'targets/xorg-i915/SConscript',
#'targets/xorg-i965/SConscript',
#'targets/xorg-nouveau/SConscript',
-#'targets/xorg-radeon/SConscript',
'targets/xorg-vmwgfx/SConscript',
])
diff --git a/src/gallium/drivers/r300/SConscript
b/src/gallium/drivers/r300/SConscript
deleted file mode 100644
index 3af157a..000
--- a/src/gallium/drivers/r300/SConscript
+++ /dev/null
@@ -1,44 +0,0 @@
-Import('*')
-
-r300compiler = SConscript('#/src/mesa/drivers/dri/r300/compiler/SConscript')
-
-env = env.Clone()
-# add the paths for r300compiler
-env.Append(CPPPATH = [
-'#/src/mesa/drivers/dri/r300/compiler',
-'#/include',
-'#/src/mesa',
-])
-
-r300 = env.ConvenienceLibrary(
-target = 'r300',
-source = [
-'r300_blit.c',
-'r300_chipset.c',
-'r300_context.c',
-'r300_debug.c',
-'r300_emit.c',
-'r300_flush.c',
-'r300_fs.c',
-'r300_hyperz.c',
-'r300_query.c',
-'r300_render.c',
-'r300_render_stencilref.c',
-'r300_render_translate.c',
-'r300_resource.c',
-'r300_screen.c',
-'r300_screen_buffer.c',
-'r300_state.c',
-'r300_state_derived.c',
-'r300_vs.c',
-'r300_vs_draw.c',
-'r300_texture.c',
-'r300_texture_desc.c',
-'r300_tgsi_to_rc.c',
-'r300_transfer.c',
-] + r300compiler) + r300compiler
-
-env.Alias('r300', r300)
-
-Export('r300')
-
diff --git a/src/gallium/targets/dri-r300/SConscript
b/src/gallium/targets/dri-r300/SConscript
deleted file mode 100644
index 683b6c6..000
--- a/src/gallium/targets/dri-r300/SConscript
+++ /dev/null
@@ -1,26 +0,0 @@
-Import('*')
-
-env = drienv.Clone()
-
-env.Append(CPPDEFINES = ['GALLIUM_RBUG', 'GALLIUM_TRACE', 'GALLIUM_GALAHAD'])
-
-env.Prepend(LIBS = [
-st_dri,
-radeonwinsys,
-r300,
-galahad,
-trace,
-rbug,
-mesa,
-glsl,
-gallium,
-COMMON_DRI_DRM_OBJECTS
-])
-
-module = env.SharedLibrary(
-target ='r300_dri.so',
-source = 'target.c',
-SHLIBPREFIX = '',
-)
-
-env.Alias('dri-r300', module)
\ No newline at end of file
diff --git a/src/gallium/targets/egl-static/SConscript
b/src/gallium/targets/egl-static/SConscript
index cbd98cc..3adc60b 100644
--- a/src/gallium/targets/egl-static/SConscript
+++ b/src/gallium/targets/egl-static/SConscript
@@ -104,10 +104,8 @@ if env['drm']:
])
if env['drm_radeon']:
-env.Append(CPPDEFINES = ['_EGL_PIPE_R300', '_EGL_PIPE_R600'])
+env.Append(CPPDEFINES = ['_EGL_PIPE_R600'])
env.Prepend(LIBS = [
-radeonwinsys,
-r300,
r600winsys,
r600,
])
diff --git a/src/gallium/winsys/SConscript b/src/gallium/winsys/SConscript
index 9f36d22..986590b 100644
--- a/src/gallium/winsys/SConscript
+++ b/src/gallium/winsys
[Mesa-dev] [PATCH 3/6] configure.ac: add option --with-gallium-drivers=DIRS
This removes all the --enable-gallium-$driver options and --disable-gallium.
Gallium can be disabled by --with-gallium-drivers= (without parameters).
Default is:
--with-gallium-drivers=r300,swrast
---
configure.ac | 165 --
1 files changed, 57 insertions(+), 108 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5d045f0..804b8a7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -549,12 +549,16 @@ AC_ARG_ENABLE([egl],
[enable_egl="$enableval"],
[enable_egl=yes])
-# Option for Gallium
-AC_ARG_ENABLE([gallium],
-[AS_HELP_STRING([--disable-gallium],
-[build gallium @<:@default=enabled@:>@])],
-[enable_gallium="$enableval"],
-[enable_gallium=yes])
+# Option for Gallium drivers
+GALLIUM_DRIVERS_DEFAULT="r300,swrast"
+
+AC_ARG_WITH([gallium-drivers],
+[AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
+[comma delimited Gallium drivers list, e.g.
+"i915,i965,nouveau,r300,r600,svga,swrast"
+@<:@default=r300,swrast@:>@])],
+[with_gallium_drivers="$withval"],
+[with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
if test "x$enable_opengl" = xno -a \
"x$enable_gles1" = xno -a \
@@ -1264,7 +1268,7 @@ if test "x$enable_openvg" = xyes; then
if test "x$enable_egl" = xno; then
AC_MSG_ERROR([cannot enable OpenVG without EGL])
fi
-if test "x$enable_gallium" = xno; then
+if test "x$with_gallium_drivers" = x; then
AC_MSG_ERROR([cannot enable OpenVG without Gallium])
fi
@@ -1280,6 +1284,10 @@ dnl D3D1X configuration
dnl
if test "x$enable_d3d1x" = xyes; then
+if test "x$with_gallium_drivers" = x; then
+AC_MSG_ERROR([cannot enable D3D1X without Gallium])
+fi
+
GALLIUM_STATE_TRACKERS_DIRS="d3d1x $GALLIUM_STATE_TRACKERS_DIRS"
HAVE_ST_D3D1X=yes
fi
@@ -1500,7 +1508,7 @@ AC_SUBST([PROGRAM_DIRS])
dnl
dnl Gallium configuration
dnl
-if test "x$enable_gallium" = xyes; then
+if test "x$with_gallium_drivers" != x; then
SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets"
AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no])
fi
@@ -1615,6 +1623,9 @@ AC_ARG_ENABLE([gallium-llvm],
[build gallium LLVM support @<:@default=enabled on x86/x86_64@:>@])],
[enable_gallium_llvm="$enableval"],
[enable_gallium_llvm=auto])
+if test "x$with_gallium_drivers" = x; then
+enable_gallium_llvm=no
+fi
if test "x$enable_gallium_llvm" = xauto; then
case "$host_cpu" in
i*86|x86_64) enable_gallium_llvm=yes;;
@@ -1660,108 +1671,46 @@ gallium_require_llvm() {
fi
}
-
-dnl
-dnl Gallium SVGA configuration
-dnl
-AC_ARG_ENABLE([gallium-svga],
-[AS_HELP_STRING([--enable-gallium-svga],
-[build gallium SVGA @<:@default=disabled@:>@])],
-[enable_gallium_svga="$enableval"],
-[enable_gallium_svga=auto])
-if test "x$enable_gallium_svga" = xyes; then
-GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga"
-gallium_check_st "svga/drm" "dri-vmwgfx" "xorg-vmwgfx"
-elif test "x$enable_gallium_svga" = xauto; then
-GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS svga"
-fi
-
-dnl
-dnl Gallium i915 configuration
-dnl
-AC_ARG_ENABLE([gallium-i915],
-[AS_HELP_STRING([--enable-gallium-i915],
-[build gallium i915 @<:@default=disabled@:>@])],
-[enable_gallium_i915="$enableval"],
-[enable_gallium_i915=auto])
-if test "x$enable_gallium_i915" = xyes; then
-GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS i915/sw"
-GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i915"
-gallium_check_st "i915/drm" "dri-i915" "xorg-i915"
-elif test "x$enable_gallium_i915" = xauto; then
+dnl Gallium drivers
+if test "x$with_gallium_drivers" != x; then
+# This is for compile-testing
+GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i915 i965 r300 svga"
GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS i915/sw"
-GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i915"
-fi
-
-dnl
-dnl Gallium i965 configuration
-dnl
-AC_ARG_ENABLE([gallium-i965],
-[AS_HELP_STRING([--enable-gallium-i965],
-[build gallium i965 @<:@default=disabled@:>@])],
-[enable_gallium_i965="$enableval"],
-[enable_gallium_i965=auto])
-if test "x$enable_gallium_i965" = xyes; then
-GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i965"
-gallium_check_st "i965/drm" "dri-i965" "xorg-i965"
-elif test "x$enable_gallium_i965" = xauto; then
-GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i965"
-fi
-
-dnl
-dnl Gallium Radeon r300g configuration
-dnl
-AC_ARG_ENABLE([gallium-r300],
-[AS_HELP_STRING([--disable-gallium-r300],
-[build R300 driver @<:@default=enabled@:>@])],
-[enable_gallium_r300="$enableval"],
-[enable_gallium_r300=yes])
-
-if test "x$enable_gallium_r300" = xyes && test "x$mesa_driver" = xdri; then
-gallium_require_llvm "Gallium R300"
-
-GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS r300"
-gallium_check_st "radeon/drm" "dri-r300" "xorg-r300"
-fi
-dnl
-dnl Gallium Radeon r600g
[Mesa-dev] [PATCH 0/6] Overhaul of Gallium configure options
Hi, This series reworks some of our configure options to make Gallium easier to configure. First, there is a new option --with-gallium-drivers=DIRS, which replaces the current heap of options --enable-gallium-DRIVER. --disable-gallium is removed as well, instead, --with-gallium-drivers= without parameters should be used to disable Gallium. --enable-gallium-egl is removed. having --enable-egl and --with-gallium-drivers=somedriver is sufficient. --with-state-trackers is removed as well. The list of state trackers is automatically deduced from the --enable-API options (the vega,egl state trackers) and --with-driver=dri|xlib (the dri,glx state trackers). Some state trackers lack an enable flag now, so these two have been added to make the list complete: --enable-xorg and --enable-d3d1x. In order to be able to "git bisect run" through this change, you can specify both the old and new options at the same time. Those that are unsupported are ignored. Other than that, I am enabling r600g by default and removing r300g and r600g from scons. I am not a fan of having multiple build systems and most people prefer autoconf anyway. It's not like anybody needs to build those drivers on Windows. Please review. BTW, one issue remains: In order to build a Gallium EGL driver, st/dri or st/xorg must be enabled (so that the driver's winsys dir is included), even though EGL and its APIs are an entirely separate project. configure.ac has no control over it. The EGL drivers are hardcoded in src/gallium/targets/egl and are compiled if their winsyses are compiled as well. Marek Olšák (6): configure.ac: remove redundant option --enable-gallium-egl configure.ac: remove --with-state-trackers configure.ac: add option --with-gallium-drivers=DIRS configure.ac: build r600g by default scons: remove r300g from the build system scons: remove r600g from the build system Makefile |1 - configure.ac | 394 - src/gallium/SConscript| 14 +- src/gallium/drivers/r300/SConscript | 44 --- src/gallium/drivers/r600/SConscript | 37 --- src/gallium/targets/dri-r300/SConscript | 26 -- src/gallium/targets/dri-r600/SConscript | 25 -- src/gallium/targets/egl-static/SConscript |9 - src/gallium/winsys/SConscript |8 - src/gallium/winsys/r600/drm/SConscript| 29 -- src/gallium/winsys/radeon/drm/SConscript | 22 -- src/mesa/drivers/dri/r300/compiler/SConscript | 51 12 files changed, 128 insertions(+), 532 deletions(-) delete mode 100644 src/gallium/drivers/r300/SConscript delete mode 100644 src/gallium/drivers/r600/SConscript delete mode 100644 src/gallium/targets/dri-r300/SConscript delete mode 100644 src/gallium/targets/dri-r600/SConscript delete mode 100644 src/gallium/winsys/r600/drm/SConscript delete mode 100644 src/gallium/winsys/radeon/drm/SConscript delete mode 100755 src/mesa/drivers/dri/r300/compiler/SConscript Best regards Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: improved is_interleaved_arrays() checking
On Tue, 2011-06-14 at 09:39 -0600, Brian Paul wrote: > Good question. I was thinking that the interleaved vs. > non-interleaved paths could probably be merged with a little work. I > don't remember the original reason for doing things as they are. I think it enabled an easier upload path within the driver/state-tracker -- memcpy a single range to a single VBO, rather than gathering. Now that the upload is potentially code-generated, that may no longer matter as much. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38301] drm: nouveau: *ERROR* Raw EDID
https://bugs.freedesktop.org/show_bug.cgi?id=38301 jukari...@gmail.com changed: What|Removed |Added Component|Drivers/DRI/nouveau |Mesa core AssignedTo|nouveau@lists.freedesktop.o |mesa-dev@lists.freedesktop. |rg |org CC||jukari...@gmail.com --- Comment #2 from jukari...@gmail.com 2011-06-14 08:52:00 PDT --- bump to mesa -- 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] st/mesa: improved is_interleaved_arrays() checking
Good question. I was thinking that the interleaved vs. non-interleaved paths could probably be merged with a little work. I don't remember the original reason for doing things as they are. -Brian On 06/14/2011 08:55 AM, Jose Fonseca wrote: Looks good Brian. BTW, does detecting interleaved arrays still provide any advantage for current HW drivers? Jose - Original Message - Check that the difference in array pointers/offsets from the 0th array are less than the stride, for both VBOs and user-space arrays. Previously, we were only doing this for the later. This tightens up the interleaved array test and fixes a problem with the llvmpipe driver where we were creating way too many vertex fetch variants only because the pipe_vertex_element::src_offset values were changing frequently. This change results in a 5x speed-up for one of the viewperf tests. Also, clean up the function to make it easier to understand. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: improved is_interleaved_arrays() checking
Looks good Brian.
BTW, does detecting interleaved arrays still provide any advantage for current
HW drivers?
Jose
- Original Message -
> Check that the difference in array pointers/offsets from the 0th
> array are less than the stride, for both VBOs and user-space arrays.
> Previously, we were only doing this for the later.
>
> This tightens up the interleaved array test and fixes a problem with
> the llvmpipe driver where we were creating way too many vertex fetch
> variants only because the pipe_vertex_element::src_offset values were
> changing frequently. This change results in a 5x speed-up for one of
> the viewperf tests.
>
> Also, clean up the function to make it easier to understand.
> ---
> src/mesa/state_tracker/st_draw.c | 50
> ++---
> 1 files changed, 19 insertions(+), 31 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_draw.c
> b/src/mesa/state_tracker/st_draw.c
> index dd26db2..1bb9b80 100644
> --- a/src/mesa/state_tracker/st_draw.c
> +++ b/src/mesa/state_tracker/st_draw.c
> @@ -237,7 +237,6 @@ st_pipe_vertex_format(GLenum type, GLuint size,
> GLenum format,
> /**
> * Examine the active arrays to determine if we have interleaved
> * vertex arrays all living in one VBO, or all living in user space.
> - * \param userSpace returns whether the arrays are in user space.
> */
> static GLboolean
> is_interleaved_arrays(const struct st_vertex_program *vp,
> @@ -247,8 +246,8 @@ is_interleaved_arrays(const struct
> st_vertex_program *vp,
> GLuint attr;
> const struct gl_buffer_object *firstBufObj = NULL;
> GLint firstStride = -1;
> - const GLubyte *client_addr = NULL;
> - GLboolean user_memory = GL_FALSE;
> + const GLubyte *firstPtr = NULL;
> + GLboolean userSpaceBuffer = GL_FALSE;
>
> for (attr = 0; attr < vpv->num_inputs; attr++) {
>const GLuint mesaAttr = vp->index_to_input[attr];
> @@ -256,37 +255,26 @@ is_interleaved_arrays(const struct
> st_vertex_program *vp,
>const struct gl_buffer_object *bufObj = array->BufferObj;
>const GLsizei stride = array->StrideB; /* in bytes */
>
> - if (firstStride < 0) {
> + if (attr == 0) {
> + /* save info about the first array */
> firstStride = stride;
> - user_memory = !bufObj || !bufObj->Name;
> - }
> - else if (firstStride != stride) {
> - return GL_FALSE;
> - }
> -
> - if (!bufObj || !bufObj->Name) {
> - /* Try to detect if the client-space arrays are
> - * "close" to each other.
> - */
> - if (!user_memory) {
> -return GL_FALSE;
> - }
> - if (!client_addr) {
> -client_addr = array->Ptr;
> - }
> - else if (abs(array->Ptr - client_addr) > firstStride) {
> -/* arrays start too far apart */
> -return GL_FALSE;
> - }
> - }
> - else if (!firstBufObj) {
> - if (user_memory) {
> -return GL_FALSE;
> - }
> + firstPtr = array->Ptr;
> firstBufObj = bufObj;
> + userSpaceBuffer = !bufObj || !bufObj->Name;
>}
> - else if (bufObj != firstBufObj) {
> - return GL_FALSE;
> + else {
> + /* check if other arrays interleave with the first, in same
> buffer */
> + if (stride != firstStride)
> +return GL_FALSE; /* strides don't match */
> +
> + if (bufObj != firstBufObj)
> +return GL_FALSE; /* arrays in different VBOs */
> +
> + if (abs(array->Ptr - firstPtr) > firstStride)
> +return GL_FALSE; /* arrays start too far apart */
> +
> + if ((!bufObj || !_mesa_is_bufferobj(bufObj)) !=
> userSpaceBuffer)
> +return GL_FALSE; /* mix of VBO and user-space arrays */
>}
> }
>
> --
> 1.7.3.4
>
> ___
> 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] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 15:21:13 +0200, Lampersperger Andreas wrote: > Which Versions of > > libdrm > mesa > xf86_video_intel > xorg-server > gtkglext > linux-kernel > > do you use? All apart from gtkglext were compiled from git with my own patches included. None of those patches were to address this issue. > You think the most suspect part is i915.ko? I watched (via systemtap) all > calls to drm_gem_object_alloc(), drm_gem_object_free(), and to > drm_gem_object_destroy() (in drm.ko) and I saw that with every > realize/unrealize of simple.c there are 2 drm_gem_object_alloc() calls > (between other drm_gem_object_allocs/frees) where I cannot found a suitable > drm_gem_object_free or .._destroy call. This leads me to suspect the > user-space. Or is this wrong, that for every drm_gem_object_alloc()-call > there have to be a drm_gem_object_free()-call? Also beware that userspace caches inactive objects. They should be released after a second or so, but that behaviour will obfuscate what is happening lower down. > Can you give me some hint, where to start debugging/watching in i915.ko? Yes, start from 2.6.39. But on second thoughts, the v2.6.33 drm_gem_vm_close() has the unref but not the close, which is a different type of leak. If the leak still occurs with 2.6.39, it is definitely in userspace. ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
Which Versions of libdrm mesa xf86_video_intel xorg-server gtkglext linux-kernel do you use? You think the most suspect part is i915.ko? I watched (via systemtap) all calls to drm_gem_object_alloc(), drm_gem_object_free(), and to drm_gem_object_destroy() (in drm.ko) and I saw that with every realize/unrealize of simple.c there are 2 drm_gem_object_alloc() calls (between other drm_gem_object_allocs/frees) where I cannot found a suitable drm_gem_object_free or .._destroy call. This leads me to suspect the user-space. Or is this wrong, that for every drm_gem_object_alloc()-call there have to be a drm_gem_object_free()-call? Can you give me some hint, where to start debugging/watching in i915.ko? -Andreas -Ursprüngliche Nachricht- Von: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Gesendet: Dienstag, 14. Juni 2011 13:37 An: Lampersperger Andreas; mesa-dev@lists.freedesktop.org Betreff: Re: AW: [Mesa-dev] leak of gem_objects on intel i965 On Tue, 14 Jun 2011 13:05:56 +0200, Lampersperger Andreas wrote: > Hello Chris, > > I have modified the simple.c from the gtkglext examples. Just replace in > gtkglext-1.2.0/examples the original simple.c with the attached version. Builds fine. I see a flashing quadric (every other frame, the gtkglarea appears unrealized) and watching /sys/kernel/debug/dri/0/i915_gem_objects, the number of bo remains static. I think the most likely suspect is i915.ko. Over the years we've had a number of gem leaks mostly associated with vma references and I'm pretty sure that they have not all been backported to 2.6.33 -Chris -- Chris Wilson, Intel Open Source Technology Centre --- Registergericht: Traunstein / Registry Court: HRB 275 – Sitz / Head Office: Traunreut Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm, Matthias Fauser, Sebastian Tondorf E-Mail Haftungsausschluss / E-Mail Disclaimer: http://www.heidenhain.de/disclaimer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 13:05:56 +0200, Lampersperger Andreas wrote: > Hello Chris, > > I have modified the simple.c from the gtkglext examples. Just replace in > gtkglext-1.2.0/examples the original simple.c with the attached version. Builds fine. I see a flashing quadric (every other frame, the gtkglarea appears unrealized) and watching /sys/kernel/debug/dri/0/i915_gem_objects, the number of bo remains static. I think the most likely suspect is i915.ko. Over the years we've had a number of gem leaks mostly associated with vma references and I'm pretty sure that they have not all been backported to 2.6.33 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.10.3 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can you please confirm the tarballs. gzip and bzip2 tarballs won't extract here throwing errors until you give tar -f parameter. I can't build packages because our packaging system uses simple bsdtar without further options. tar -tvf ~/arch64/sources/MesaLib-7.10.2.tar.gz | grep ^h shows nothing for the working older releases but many broken links in the new archives. [andyrtr@workstation64 foo]$ LANG=C tar -tvf ~/arch64/sources/MesaLib-7.10.3.tar.gz | grep ^h hrw-rw-r-- idr/idr 0 2011-05-20 10:31 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c hrw-r--r-- idr/idr 0 2010-10-05 18:56 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.h hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog_emit.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog_emit.c hrw-r--r-- idr/idr 0 2010-10-19 19:58 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog.h hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog_swizzle.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog_swizzle.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog_swizzle.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r300_fragprog_swizzle.h hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog.c hrw-r--r-- idr/idr 0 2010-10-19 19:58 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r500_fragprog.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r500_fragprog.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r500_fragprog.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/r500_fragprog.h hrw-r--r-- idr/idr 0 2010-12-14 22:43 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_code.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_code.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_code.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_code.h hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler.h hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler_util.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler_util.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler_util.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_compiler_util.h hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow_deadcode.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow_deadcode.c hrw-rw-r-- idr/idr 0 2011-05-20 10:33 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow.h link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow.h hrw-r--r-- idr/idr 0 2011-01-02 23:58 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow_swizzles.c link to Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_dataflow_swizzles.c hrw-r--r-- idr/idr 0 2010-12-14 22:43 Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/radeon_emulate_branc
Re: [Mesa-dev] leak of gem_objects on intel i965
Hello Chris,
I have modified the simple.c from the gtkglext examples. Just replace in
gtkglext-1.2.0/examples the original simple.c with the attached version.
-Andreas
-Ursprüngliche Nachricht-
Von: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Gesendet: Dienstag, 14. Juni 2011 12:50
An: Lampersperger Andreas; mesa-dev@lists.freedesktop.org
Betreff: Re: [Mesa-dev] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 12:20:28 +0200, Lampersperger Andreas
wrote:
> Hello,
>
> running my application over a long time results in a kernel freeze or OOM
> kill, because reparenting a gtkglext drawing area on a intel i965 causes a
> leak of gem_objects.
That sounds like a simple test case to concoct. Do you have one handy?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
/*
* simple.c:
* Simple GtkGLExt example.
*
* written by Naofumi Yasufuku
*/
#include
#include
#include
#include
#ifdef G_OS_WIN32
#define WIN32_LEAN_AND_MEAN 1
#include
#endif
#include
#include
#include
static void
realize (GtkWidget *widget,
gpointer data)
{
GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
GLUquadricObj *qobj;
static GLfloat light_diffuse[] = {1.0, 0.0, 0.0, 1.0};
static GLfloat light_position[] = {1.0, 1.0, 1.0, 0.0};
/*** OpenGL BEGIN ***/
if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
return;
qobj = gluNewQuadric ();
gluQuadricDrawStyle (qobj, GLU_FILL);
glNewList (1, GL_COMPILE);
gluSphere (qobj, 1.0, 20, 20);
glEndList ();
glLightfv (GL_LIGHT0, GL_DIFFUSE, light_diffuse);
glLightfv (GL_LIGHT0, GL_POSITION, light_position);
glEnable (GL_LIGHTING);
glEnable (GL_LIGHT0);
glEnable (GL_DEPTH_TEST);
glClearColor (1.0, 1.0, 1.0, 1.0);
glClearDepth (1.0);
glViewport (0, 0,
widget->allocation.width, widget->allocation.height);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
gluPerspective (40.0, 1.0, 1.0, 10.0);
glMatrixMode (GL_MODELVIEW);
glLoadIdentity ();
gluLookAt (0.0, 0.0, 3.0,
0.0, 0.0, 0.0,
0.0, 1.0, 0.0);
glTranslatef (0.0, 0.0, -3.0);
gdk_gl_drawable_gl_end (gldrawable);
/*** OpenGL END ***/
}
static gboolean
configure_event (GtkWidget *widget,
GdkEventConfigure *event,
gpointer data)
{
GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
printf("configure_event gl_context %p \n", glcontext);
/*** OpenGL BEGIN ***/
if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
return FALSE;
glViewport (0, 0,
widget->allocation.width, widget->allocation.height);
gdk_gl_drawable_gl_end (gldrawable);
/*** OpenGL END ***/
return TRUE;
}
static gboolean
expose_event (GtkWidget *widget,
GdkEventExpose *event,
gpointerdata)
{
GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
/*** OpenGL BEGIN ***/
if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
return FALSE;
glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glCallList (1);
if (gdk_gl_drawable_is_double_buffered (gldrawable))
gdk_gl_drawable_swap_buffers (gldrawable);
else
glFlush ();
gdk_gl_drawable_gl_end (gldrawable);
/*** OpenGL END ***/
return TRUE;
}
#define TAKT 500
static guint timeout_id = 0;
static GtkWidget *window = NULL;
static void timeout_add (GtkWidget *widget);
static void timeout_remove (GtkWidget *widget);
static GtkWidget *vbox = NULL;
static GtkWidget *drawing_area = NULL;
static GtkWidget *tempPlug = NULL;
static gboolean
timeout (GtkWidget *widget)
{
static int is_unmapped = 0;
GdkGLContext *glcontext = gtk_widget_get_gl_context (drawing_area);
timeout_remove(widget);
if (is_unmapped == 0) {
printf("map out --- gl_context %p \n", glcontext);
gtk_widget_reparent(drawing_area, tempPlug);
is_unmapped = 1;
}
else {
printf("map in gl_context %p \n", glcontext);
gtk_widget_reparent(drawing_area, vbox);
is_unmapped = 0;
}
timeout_add (widget);
return TRUE;
}
static void
timeout_remove (GtkWidget *widget) {
if (timeout_id != 0)
{
g_source_remove (timeout_id);
timeout_id = 0;
}
}
static void
timeout_add (GtkWidget *widget)
{
if (timeout_id == 0)
{
timeout_id = g_timeout_add (TAKT,
(GSourceFunc) timeout,
window);
}
}
int
main (int argc,
char *argv[])
{
GdkGLConfig *glconfig;
gint major, minor;
GtkWidget *button;
/*
* Init GTK.
*/
gtk_in
Re: [Mesa-dev] leak of gem_objects on intel i965
On Tue, 14 Jun 2011 12:20:28 +0200, Lampersperger Andreas wrote: > Hello, > > running my application over a long time results in a kernel freeze or OOM > kill, because reparenting a gtkglext drawing area on a intel i965 causes a > leak of gem_objects. That sounds like a simple test case to concoct. Do you have one handy? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] leak of gem_objects on intel i965
Hello, running my application over a long time results in a kernel freeze or OOM kill, because reparenting a gtkglext drawing area on a intel i965 causes a leak of gem_objects. I use the following versions: kernel 2.6.33.9 libdrm 2.4.23 xorg-server 1.10.2 xf86-video-intel-2.15 gtkglext-1.2.0 mesa 7.10.2 Does anyone know if there is known bug with this versions and a leak of gem_objects on intel i965? I did a lot of debugging the last weeks, but I have no glue, where/how the buffers have to be freed, which are requested from the xserver in the function DRI2GetBuffersWithFormat(..) at dri2.c:431. Can anyone explain to me how these buffers are managed? Through debugging I made the following guess: The reference to the buffers requestet from Xserver via DRI2GetBuffersWithFormat(..) are kept in "loaderPrivate" struct of a __DRIdrawable, is this right? But I found no code where these buffers are unreferenced/destroyed/freed. Thanks for any answer. Andreas --- Registergericht: Traunstein / Registry Court: HRB 275 – Sitz / Head Office: Traunreut Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / Chairman), Michael Grimm, Matthias Fauser, Sebastian Tondorf E-Mail Haftungsausschluss / E-Mail Disclaimer: http://www.heidenhain.de/disclaimer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Various patches
On Monday, June 13, 2011 17:55:35 Alex Deucher wrote: > These first 4 look good to me. I've done a piglit run with them and > no regressions. I've gone ahead and applied them. Thanks! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: Split _mesa_generate_mipmap along compressed/uncompressed lines.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/2011 01:42 PM, Eric Anholt wrote:
> The path taken is wildly different based on this (do we generate from
> a temporary image, or from level-1's data), and we appear to have
> stride bugs in the compressed case that are tough to disentangle.
>
> This just duplicates the code for the moment, the followon commit will
> do the actual changes. Only real code change here is handling
> maxLevel in one common place.
> ---
> src/mesa/main/mipmap.c | 251
> +++-
> 1 files changed, 225 insertions(+), 26 deletions(-)
>
> diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
> index e9fcb54..2bdb111 100644
> --- a/src/mesa/main/mipmap.c
> +++ b/src/mesa/main/mipmap.c
> @@ -1885,38 +1885,208 @@ next_mipmap_level_size(GLenum target, GLint border,
> }
> }
>
> +static void
> +generate_mipmap_uncompressed(struct gl_context *ctx, GLenum target,
> + struct gl_texture_object *texObj,
> + const struct gl_texture_image *srcImage,
> + GLuint maxLevel)
> +{
> + GLint level;
> + gl_format convertFormat;
> + const GLubyte *srcData = NULL;
> + GLubyte *dstData = NULL;
> + GLenum datatype;
> + GLuint comps;
>
> + /* Find convertFormat - the format that do_row() will process */
> + if (_mesa_is_format_compressed(srcImage->TexFormat)) {
> + /* setup for compressed textures - need to allocate temporary
> + * image buffers to hold uncompressed images.
> + */
> + GLuint row;
> + GLint components, size;
> + GLchan *dst;
>
> + assert(texObj->Target == GL_TEXTURE_2D ||
> + texObj->Target == GL_TEXTURE_CUBE_MAP_ARB);
|| texObj->Target == GL_TEXTURE_2D_ARRAY);
>
> -/**
> - * Automatic mipmap generation.
> - * This is the fallback/default function for ctx->Driver.GenerateMipmap().
> - * Generate a complete set of mipmaps from texObj's BaseLevel image.
> - * Stop at texObj's MaxLevel or when we get to the 1x1 texture.
> - * For cube maps, target will be one of
> - * GL_TEXTURE_CUBE_MAP_POSITIVE/NEGATIVE_X/Y/Z; never GL_TEXTURE_CUBE_MAP.
> - */
> -void
> -_mesa_generate_mipmap(struct gl_context *ctx, GLenum target,
> - struct gl_texture_object *texObj)
> + if (srcImage->_BaseFormat == GL_RGB) {
> + convertFormat = MESA_FORMAT_RGB888;
> + components = 3;
> + } else if (srcImage->_BaseFormat == GL_RED) {
> + convertFormat = MESA_FORMAT_R8;
> + components = 1;
> + } else if (srcImage->_BaseFormat == GL_RG) {
> + convertFormat = MESA_FORMAT_RG88;
> + components = 2;
> + } else if (srcImage->_BaseFormat == GL_RGBA) {
> + convertFormat = MESA_FORMAT_RGBA;
> + components = 4;
> + } else if (srcImage->_BaseFormat == GL_LUMINANCE) {
> + convertFormat = MESA_FORMAT_L8;
> + components = 1;
> + } else if (srcImage->_BaseFormat == GL_LUMINANCE_ALPHA) {
> + convertFormat = MESA_FORMAT_AL88;
> + components = 2;
> + } else {
> + _mesa_problem(ctx, "bad srcImage->_BaseFormat in
> _mesa_generate_mipmaps");
> + return;
> + }
> +
> + /* allocate storage for uncompressed GL_RGB or GL_RGBA images */
> + size = _mesa_bytes_per_pixel(srcImage->_BaseFormat, CHAN_TYPE)
> + * srcImage->Width * srcImage->Height * srcImage->Depth + 20;
> + /* 20 extra bytes, just be safe when calling last FetchTexel */
> + srcData = (GLubyte *) malloc(size);
> + if (!srcData) {
> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "generate mipmaps");
> + return;
> + }
> + dstData = (GLubyte *) malloc(size / 2); /* 1/4 would probably be OK */
> + if (!dstData) {
> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "generate mipmaps");
> + free((void *) srcData);
> + return;
> + }
> +
> + /* decompress base image here */
> + dst = (GLchan *) srcData;
> + for (row = 0; row < srcImage->Height; row++) {
> + GLuint col;
> + for (col = 0; col < srcImage->Width; col++) {
> +srcImage->FetchTexelc(srcImage, col, row, 0, dst);
> +dst += components;
> + }
> + }
> + }
> + else {
> + /* uncompressed */
> + convertFormat = srcImage->TexFormat;
> + }
> +
> + _mesa_format_to_type_and_comps(convertFormat, &datatype, &comps);
> +
> + for (level = texObj->BaseLevel; level < maxLevel; level++) {
> + /* generate image[level+1] from image[level] */
> + const struct gl_texture_image *srcImage;
> + struct gl_texture_image *dstImage;
> + GLint srcWidth, srcHeight, srcDepth;
> + GLint dstWidth, dstHeight, dstDepth;
> + GLint border;
> + GLboolean nextLevel;
> +
> + /* get src image parameters */
> + srcImage = _mesa_select_tex_image(ctx, texObj, target, level);
> +
Re: [Mesa-dev] [PATCH 03/11] intel: Add block alignment for RGTC textures.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/2011 03:44 PM, Eric Anholt wrote:
> On Fri, 10 Jun 2011 15:17:12 -0600, Brian Paul wrote:
>> On 06/10/2011 02:38 PM, Eric Anholt wrote:
>>> We were using the default 4x2 alignment instead of the 4x4 required
>>> for non-FXT compressed textures.
>>> ---
>>> src/mesa/drivers/dri/i965/brw_tex_layout.c |2 +-
>>> src/mesa/drivers/dri/intel/intel_mipmap_tree.c |6 +--
>>> src/mesa/drivers/dri/intel/intel_tex_layout.c | 42
>>> +---
>>> src/mesa/drivers/dri/intel/intel_tex_layout.h |3 +-
>>> 4 files changed, 21 insertions(+), 32 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
>>> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
>>> index 4a3a2bf..f462f32 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
>>> @@ -88,7 +88,7 @@ GLboolean brw_miptree_layout(struct intel_context *intel,
>>> GLuint align_w = 4;
>>>
>>> mt->total_height = 0;
>>> -
>>> intel_get_texture_alignment_unit(mt->internal_format,&align_w,&align_h);
>>> + intel_get_texture_alignment_unit(mt->format,&align_w,&align_h);
>>>
>>> if (mt->compressed) {
>>> mt->total_width = ALIGN(width, align_w);
>>> diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
>>> b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
>>> index aa6fc5b..9a1fb18 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
>>> @@ -402,8 +402,7 @@ intel_miptree_image_data(struct intel_context *intel,
>>> if(dst->compressed) {
>>> unsigned int align_w, align_h;
>>>
>>> -intel_get_texture_alignment_unit(dst->internal_format,
>>> - &align_w,&align_h);
>>> +intel_get_texture_alignment_unit(dst->format,&align_w,&align_h);
>>> height = (height + align_h - 1) / align_h;
>>> width = ALIGN(width, align_w);
>>> }
>>> @@ -445,8 +444,7 @@ intel_miptree_image_copy(struct intel_context *intel,
>>> if (dst->compressed) {
>>> GLuint align_w, align_h;
>>>
>>> - intel_get_texture_alignment_unit(dst->internal_format,
>>> -&align_w,&align_h);
>>> + intel_get_texture_alignment_unit(dst->format,&align_w,&align_h);
>>> height = (height + 3) / 4;
>>> width = ALIGN(width, align_w);
>>> }
>>> diff --git a/src/mesa/drivers/dri/intel/intel_tex_layout.c
>>> b/src/mesa/drivers/dri/intel/intel_tex_layout.c
>>> index d39733b..7493b42 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_tex_layout.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_tex_layout.c
>>> @@ -35,32 +35,22 @@
>>> #include "intel_context.h"
>>> #include "main/macros.h"
>>>
>>> -void intel_get_texture_alignment_unit(GLenum internalFormat, GLuint *w,
>>> GLuint *h)
>>> +void
>>> +intel_get_texture_alignment_unit(gl_format format,
>>> +unsigned int *w, unsigned int *h)
>>> {
>>> -switch (internalFormat) {
>>> -case GL_COMPRESSED_RGB_FXT1_3DFX:
>>> -case GL_COMPRESSED_RGBA_FXT1_3DFX:
>>> -*w = 8;
>>> -*h = 4;
>>> -break;
>>> -
>>> -case GL_RGB_S3TC:
>>> -case GL_RGB4_S3TC:
>>> -case GL_COMPRESSED_RGB_S3TC_DXT1_EXT:
>>> -case GL_COMPRESSED_RGBA_S3TC_DXT1_EXT:
>>> -case GL_RGBA_S3TC:
>>> -case GL_RGBA4_S3TC:
>>> -case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
>>> -case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
>>> -*w = 4;
>>> -*h = 4;
>>> -break;
>>> -
>>> -default:
>>> -*w = 4;
>>> -*h = 2;
>>> -break;
>>> -}
>>> + if (_mesa_is_format_compressed(format)) {
>>> + if (format == MESA_FORMAT_RGB_FXT1 || format ==
>>> MESA_FORMAT_RGBA_FXT1) {
>>> +*w = 8;
>>> +*h = 4;
>>> + } else {
>>> +*w = 4;
>>> +*h = 4;
>>> + }
>>> + } else {
>>> + *w = 4;
>>> + *h = 2;
>>> + }
>>
>> Could you make use of _mesa_get_format_block_size() here?
>
> The compressed formats happen to match, but the default case doesn't.
> Given that this is coming out of a table in the hardware spec (and we're
> going to need a bunch of overrides for it in the future with MSAA and
> things), I'd rather just reproduce the hw spec here.
But it should match for all the compressed formats, right? I think
Brian was suggesting to use _mesa_get_format_block_size just for the
compressed formats. Some day there will be more compressed formats. *shrug*
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk3yvNsACgkQX1gOwKyEAw80AgCffQYULVx7ap+ZzG5XC+j8xtYi
uDIAoJjWQMw/E6f2ORHHPlwTnFsm6BT1
=5Uv6
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
