[Mesa-dev] [Bug 41221] Mesa 7.11 implementation error: Incomplete OpenGL ES 2.0 support.
https://bugs.freedesktop.org/show_bug.cgi?id=41221 --- Comment #1 from Tapani Pälli lem...@gmail.com 2011-10-18 03:12:42 PDT --- What is the graphics HW used and can you upload the test application as an attachment? Have you tried running es2tri in mesa demos? For me OpenGL ES 2.0 applications compile and run fine with Mesa 7.11 on Intel and on Nvidia. -- 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] sd
b___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] implicit declaration of function wl_drm_create
Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/targets: Add vdpau target for nouveau
Should fall back to shader based decoding (g3dvl) for now.
This is probably broken on systems that support xvmc, because
nouveau_video_buffer_create has no way to know for what api
the buffer is created, so I think this call might need a
separate argument as workaround.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
diff --git a/configure.ac b/configure.ac
index 0864b55..3696145 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1858,7 +1858,7 @@ if test x$with_gallium_drivers != x; then
xnouveau)
PKG_CHECK_MODULES([NOUVEAU], [libdrm_nouveau =
$LIBDRM_NOUVEAU_REQUIRED])
GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS nouveau nvfx nv50 nvc0
-gallium_check_st nouveau/drm dri-nouveau xorg-nouveau
xvmc-nouveau
+gallium_check_st nouveau/drm dri-nouveau xorg-nouveau
xvmc-nouveau vdpau-nouveau
;;
xswrast)
GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS softpipe
diff --git a/src/gallium/targets/vdpau-nouveau/Makefile
b/src/gallium/targets/vdpau-nouveau/Makefile
new file mode 100644
index 000..55f9907
--- /dev/null
+++ b/src/gallium/targets/vdpau-nouveau/Makefile
@@ -0,0 +1,28 @@
+TOP = ../../../..
+include $(TOP)/configs/current
+
+LIBBASENAME = vdpau_nouveau
+
+PIPE_DRIVERS = \
+ $(TOP)/src/gallium/winsys/g3dvl/dri/libvldri.a \
+ $(TOP)/src/gallium/winsys/nouveau/drm/libnouveaudrm.a \
+ $(TOP)/src/gallium/drivers/nvfx/libnvfx.a \
+ $(TOP)/src/gallium/drivers/nv50/libnv50.a \
+ $(TOP)/src/gallium/drivers/nvc0/libnvc0.a \
+ $(TOP)/src/gallium/drivers/nouveau/libnouveau.a \
+ $(TOP)/src/gallium/drivers/trace/libtrace.a \
+ $(TOP)/src/gallium/auxiliary/libgallium.a
+
+
+C_SOURCES = \
+ target.c \
+ $(COMMON_GALLIUM_SOURCES) \
+ $(DRIVER_SOURCES)
+
+DRIVER_LIBS = $(shell $(PKG_CONFIG) libdrm_nouveau --libs) -lXfixes
+
+LINK_WITH_CXX=1
+
+include ../Makefile.vdpau
+
+symlinks:
diff --git a/src/gallium/targets/vdpau-nouveau/target.c
b/src/gallium/targets/vdpau-nouveau/target.c
new file mode 100644
index 000..d580b10
--- /dev/null
+++ b/src/gallium/targets/vdpau-nouveau/target.c
@@ -0,0 +1,18 @@
+#include state_tracker/drm_driver.h
+#include target-helpers/inline_debug_helper.h
+#include nouveau/drm/nouveau_drm_public.h
+
+static struct pipe_screen *create_screen(int fd)
+{
+ struct pipe_screen *screen;
+
+ screen = nouveau_drm_screen_create(fd);
+ if (!screen)
+ return NULL;
+
+ screen = debug_screen_wrap(screen);
+
+ return screen;
+}
+
+DRM_DRIVER_DESCRIPTOR(nouveau, nouveau, create_screen, NULL)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix multithreaded buffer object refcounting.
On 10/17/2011 10:59 PM, Mathias Fröhlich wrote: Hi, Attached is a change to core mesa. This fixes a potential refcount locking problem with shared OpenGL objects. This change survives a piglit r600 run on my local machine. Please review. This was brought up a few weeks ago by someone else. I had posted the start of a patch to fix it. I'm attaching an updated version that I think is pretty clean. But there's a few lines missing and it's totally untested. Maybe you could finish this up. Look for 'XXX' comments. -Brian push-pop-arrays.patch Description: application/pgp-keys ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] implicit declaration of function wl_drm_create
2011/10/18 chris wwzbw...@163.com Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? It comes from wayland: http://cgit.freedesktop.org/wayland Check out the wayland and wayland-demos projects. -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa,swrast,vbo,meta: Prepare for HiZ on i965
On 10/17/2011 08:27 AM, Chad Versace wrote: HiZ is near completion on i965, and it requires some preliminary changes to core Mesa. No big changes here; a quick bugfix, redeclaring functions as non-static, and adding an extra meta-op flag and some functions to the Driver vtbl. The core Mesa stuff looks good to me. One minor nit: in patch 5/6 put a space after your ifs: 'if(x)' - 'if (x)' Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] implicit declaration of function wl_drm_create
2011/10/18 chris wwzbw...@163.com: Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? It's defined in the code generated from the drm.xml definition. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41969] New: The Mesa meta save/restore code doesn't always save the active program
https://bugs.freedesktop.org/show_bug.cgi?id=41969 Bug #: 41969 Summary: The Mesa meta save/restore code doesn't always save the active program Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: n...@linux.intel.com Looks like there is a cut and paste error which means the meta save/restore code won't save the active program if it doesn't have a fragment shader. Please see the patch. -- 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 41969] The Mesa meta save/restore code doesn't always save the active program
https://bugs.freedesktop.org/show_bug.cgi?id=41969 --- Comment #1 from Neil Roberts n...@linux.intel.com 2011-10-18 10:52:06 PDT --- Created attachment 52487 -- https://bugs.freedesktop.org/attachment.cgi?id=52487 meta: Fix saving the active program When saving the active program in _mesa_meta_begin, it was actually saving the fragment program instead. This means that if the application binds a program that only has a vertex shader then when the meta saved state is restored it will forget the bound program. -- 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] mesa: Remove unnecessary and incorrect TexEnv parameter validation.
For GL_RGB_SCALE and GL_ALPHA_SCALE targets, the API wrapper code attempts to ensure the parameter is 1.0, 2.0, or 4.0. This is unnecessary: set_combiner_scale in texenv.c (called by _mesa_TexEnvfv) already checks this and raises an appropriate error. It's also incorrect: For glTexEnvx, the API validation code directly compares the GLfixed input parameter with a floating point constant, prior to converting fixed-point to floating point. Fixes an issue in the OpenGL ES 1.1 conformance suite. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/main/APIspec.xml |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml index 574480e..a92bb43 100644 --- a/src/mesa/main/APIspec.xml +++ b/src/mesa/main/APIspec.xml @@ -631,12 +631,6 @@ desc name=pname value name=GL_RGB_SCALE/ value name=GL_ALPHA_SCALE/ - - desc name=param convert=true error=GL_INVALID_VALUE - value name=1.0/ - value name=2.0/ - value name=4.0/ - /desc /desc desc name=pname -- 1.7.7 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 41969] The Mesa meta save/restore code doesn't always save the active program
https://bugs.freedesktop.org/show_bug.cgi?id=41969 Chad Versace c...@chad-versace.us changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Chad Versace c...@chad-versace.us 2011-10-18 11:14:18 PDT --- Thanks Neil. I've pushed the patch and am marking the bug as RESOLVED/FIXED. -- 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: Enable faster workaround-free math on Ivybridge.
According to the documentation, Ivybridge's math instruction works in
SIMD16 mode for the fragment shader, and no longer forbids align16 mode
for the vertex shader.
The documentation claims that SIMD16 mode isn't supported for INT DIV,
but empirical evidence shows that it works fine. Presumably the note
is trying to warn us that the variant that returns both quotient and
remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1
would be sechalf(dst), trashing half your results. Since we don't use
that variant, we don't care and can just enable SIMD16 everywhere.
The documentation also still claims that source modifiers and
conditional modifiers aren't supported, but empirical evidence and
study of the simulator both show that they work just fine.
Goodbye workarounds. Math just works now.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 29 +++-
src/mesa/drivers/dri/i965/brw_fs.cpp|6 +++-
src/mesa/drivers/dri/i965/brw_fs.h |7 ++
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 31 ++-
src/mesa/drivers/dri/i965/brw_vec4.h|4 +++
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 19 ++-
6 files changed, 80 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 5caebfc..0841478 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -1496,11 +1496,14 @@ void brw_math( struct brw_compile *p,
assert(src.file == BRW_GENERAL_REGISTER_FILE);
assert(dest.hstride == BRW_HORIZONTAL_STRIDE_1);
- assert(src.hstride == BRW_HORIZONTAL_STRIDE_1);
+ if (intel-gen == 6)
+assert(src.hstride == BRW_HORIZONTAL_STRIDE_1);
- /* Source modifiers are ignored for extended math instructions. */
- assert(!src.negate);
- assert(!src.abs);
+ /* Source modifiers are ignored for extended math instructions on Gen6.
*/
+ if (intel-gen == 6) {
+assert(!src.negate);
+assert(!src.abs);
+ }
if (function == BRW_MATH_FUNCTION_INT_DIV_QUOTIENT ||
function == BRW_MATH_FUNCTION_INT_DIV_REMAINDER ||
@@ -1560,8 +1563,10 @@ void brw_math2(struct brw_compile *p,
assert(src1.file == BRW_GENERAL_REGISTER_FILE);
assert(dest.hstride == BRW_HORIZONTAL_STRIDE_1);
- assert(src0.hstride == BRW_HORIZONTAL_STRIDE_1);
- assert(src1.hstride == BRW_HORIZONTAL_STRIDE_1);
+ if (intel-gen == 6) {
+ assert(src0.hstride == BRW_HORIZONTAL_STRIDE_1);
+ assert(src1.hstride == BRW_HORIZONTAL_STRIDE_1);
+ }
if (function == BRW_MATH_FUNCTION_INT_DIV_QUOTIENT ||
function == BRW_MATH_FUNCTION_INT_DIV_REMAINDER ||
@@ -1573,11 +1578,13 @@ void brw_math2(struct brw_compile *p,
assert(src1.type == BRW_REGISTER_TYPE_F);
}
- /* Source modifiers are ignored for extended math instructions. */
- assert(!src0.negate);
- assert(!src0.abs);
- assert(!src1.negate);
- assert(!src1.abs);
+ /* Source modifiers are ignored for extended math instructions on Gen6. */
+ if (intel-gen == 6) {
+ assert(!src0.negate);
+ assert(!src0.abs);
+ assert(!src1.negate);
+ assert(!src1.abs);
+ }
/* Math is the same ISA format as other opcodes, except that CondModifier
* becomes FC[3:0] and ThreadCtrl becomes FC[5:4].
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index f731662..6c417d4 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -554,7 +554,7 @@ fs_visitor::emit_math(enum opcode opcode, fs_reg dst,
fs_reg src)
* The hardware ignores source modifiers (negate and abs) on math
* instructions, so we also move to a temp to set those up.
*/
- if (intel-gen = 6 (src.file == UNIFORM ||
+ if (intel-gen == 6 (src.file == UNIFORM ||
src.abs ||
src.negate)) {
fs_reg expanded = fs_reg(this, glsl_type::float_type);
@@ -588,7 +588,9 @@ fs_visitor::emit_math(enum opcode opcode, fs_reg dst,
fs_reg src0, fs_reg src1)
return NULL;
}
- if (intel-gen = 6) {
+ if (intel-gen = 7) {
+ inst = emit(opcode, dst, src0, src1);
+ } else if (intel-gen == 6) {
/* Can't do hstride == 0 args to gen6 math, so expand it out.
*
* The hardware ignores source modifiers (negate and abs) on math
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 4035186..85d3cad 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -490,6 +490,13 @@ public:
void generate_linterp(fs_inst *inst, struct brw_reg dst,
struct brw_reg *src);
void generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg src);
+ void generate_math1_gen7(fs_inst
Re: [Mesa-dev] Fixed function fragment shader to GLSL
- Original Message - Here's this patch series again, part of the kill-Mesa-IR goal we have for next release. It's been no regressions for me for a while, I was just trying to track down a 2% performance regression on gen6. It turns out that on my gen4 system, it's no performance regression, and on gen7 (at least according to testing with the followon patches to use the new coegen), it's a ~4% performance win. While many things were learned in the process, the cause of the 2% loss appears to come down to some GPU instruction pipelining issue with lots of handwaving on my part. When using the new backend, we generate like 1/3 fewer instructions (after accounting for the 8/16 compile). I'm not including the patches for using the new backend quite yet, as there's a functional regression on gm45 in the new backend that I need to track down first. Hi, I know I told you to wait till Monday but I didn't get around to take a look at the changes, sorry about that, tho I would have appreciated that you at least pinged me before you pushed the changes. While you say tested the changes I assume you didn't test any Gallium driver (which you probably should since the only real driver in use today that isn't Gallium is i965). I'm also assuming this patch series will have the previous set of regressions as I outlined the last time this was up for discussion. http://article.gmane.org/gmane.comp.video.mesa3d.devel/24837 Also I would appreciated these kind of change the whole world changes to have a larger Acked-by/Reviewed-by base the just one other guy using the same test set as the author. Would it be possible to do the same resolution as before until we can actually discuss this change. Cheers, Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: Add support for constant expression evaluation on round(), roundEven().
v2: Avoid the C99 rounding functions, because I don't trust
get/setting the C99 rounding mode from inside our library not having
other side effects. Instead, open-code roundEven() behavior around
Mesa's IROUND, which we're already testing for C99 rounding mode
safety.
Fixes glsl-1.30/compiler/built-in-functions/round*
---
src/glsl/ir_constant_expression.cpp | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index b3fe6cf..83f084d 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -39,6 +39,25 @@
#include ir_visitor.h
#include glsl_types.h
+/* Using C99 rounding functions for roundToEven() implementation is
+ * difficult, because round(), rint, and nearbyint() are affected by
+ * fesetenv(), which the application may have done for its own
+ * purposes. Mesa's IROUND macro is close to what we want, but it
+ * rounds away from 0 on n + 0.5.
+ */
+static int
+round_to_even(float val)
+{
+ int rounded = IROUND(val);
+
+ if (val - floor(val) == 0.5) {
+ if (rounded % 2 != 0)
+rounded += val 0 ? -1 : 1;
+ }
+
+ return rounded;
+}
+
static float
dot(ir_constant *op0, ir_constant *op1)
{
@@ -196,6 +215,13 @@ ir_expression::constant_expression_value()
}
break;
+ case ir_unop_round_even:
+ assert(op[0]-type-base_type == GLSL_TYPE_FLOAT);
+ for (unsigned c = 0; c op[0]-type-components(); c++) {
+data.f[c] = round_to_even(op[0]-value.f[c]);
+ }
+ break;
+
case ir_unop_ceil:
assert(op[0]-type-base_type == GLSL_TYPE_FLOAT);
for (unsigned c = 0; c op[0]-type-components(); c++) {
@@ -1324,6 +1350,9 @@ ir_call::constant_expression_value()
* op[1]-value.f[c];
}
}
+ } else if (strcmp(callee, round) == 0 ||
+ strcmp(callee, roundEven) == 0) {
+ expr = new(mem_ctx) ir_expression(ir_unop_round_even, op[0]);
} else if (strcmp(callee, sign) == 0) {
expr = new(mem_ctx) ir_expression(ir_unop_sign, type, op[0], NULL);
} else if (strcmp(callee, sin) == 0) {
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: Round the argument to PixelStoref instead of truncating.
From the GL 2.1 specification, page 114 (page 128 of the PDF):
The version of PixelStore that takes a floating-point value
may be used to set any type of parameter; if the parameter is
boolean, then it is set to FALSE if the passed value is 0.0
and TRUE otherwise, while if the parameter is an integer, then
the passed value is rounded to the nearest integer.
Fixes piglit roundmode-pixelstore.
---
src/mesa/main/pixelstore.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/pixelstore.c b/src/mesa/main/pixelstore.c
index d957950..8147449 100644
--- a/src/mesa/main/pixelstore.c
+++ b/src/mesa/main/pixelstore.c
@@ -214,7 +214,7 @@ _mesa_PixelStorei( GLenum pname, GLint param )
void GLAPIENTRY
_mesa_PixelStoref( GLenum pname, GLfloat param )
{
- _mesa_PixelStorei( pname, (GLint) param );
+ _mesa_PixelStorei( pname, IROUND(param) );
}
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fixed function fragment shader to GLSL
On 10/18/2011 11:39 AM, Jakob Bornecrantz wrote: - Original Message - Here's this patch series again, part of the kill-Mesa-IR goal we have for next release. It's been no regressions for me for a while, I was just trying to track down a 2% performance regression on gen6. It turns out that on my gen4 system, it's no performance regression, and on gen7 (at least according to testing with the followon patches to use the new coegen), it's a ~4% performance win. While many things were learned in the process, the cause of the 2% loss appears to come down to some GPU instruction pipelining issue with lots of handwaving on my part. When using the new backend, we generate like 1/3 fewer instructions (after accounting for the 8/16 compile). I'm not including the patches for using the new backend quite yet, as there's a functional regression on gm45 in the new backend that I need to track down first. Hi, I know I told you to wait till Monday but I didn't get around to take a look at the changes, sorry about that, tho I would have appreciated that you at least pinged me before you pushed the changes. While you say tested the changes I assume you didn't test any Gallium driver (which you probably should since the only real driver in use today that isn't Gallium is i965). I'm also assuming this patch series will have the previous set of regressions as I outlined the last time this was up for discussion. http://article.gmane.org/gmane.comp.video.mesa3d.devel/24837 Also I would appreciated these kind of change the whole world changes to have a larger Acked-by/Reviewed-by base the just one other guy using the same test set as the author. Would it be possible to do the same resolution as before until we can actually discuss this change. Cheers, Jakob. We can't stall this forever...it's critical for our future work. You had two weeks to comment (10/06 to 10/18); that should have been plenty of time. Not to mention the fact that this was originally proposed clear back in January...this should come as no surprise. Also, the issues you raised 9 months ago about code generation most likely no longer apply: Gallium now uses Bryan Cain's new st_glsl_to_tgsi translator, which includes its own optimization passes. At any rate, a new investigation is needed. I'm strongly opposed to reverting this again, especially for unbounded amounts of time like before. This is the future. If there are remaining issues, let's just go ahead and fix them... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: Round the argument to PixelStoref instead of truncating.
On 10/18/2011 01:31 PM, Eric Anholt wrote:
From the GL 2.1 specification, page 114 (page 128 of the PDF):
The version of PixelStore that takes a floating-point value
may be used to set any type of parameter; if the parameter is
boolean, then it is set to FALSE if the passed value is 0.0
and TRUE otherwise, while if the parameter is an integer, then
the passed value is rounded to the nearest integer.
Fixes piglit roundmode-pixelstore.
---
src/mesa/main/pixelstore.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/pixelstore.c b/src/mesa/main/pixelstore.c
index d957950..8147449 100644
--- a/src/mesa/main/pixelstore.c
+++ b/src/mesa/main/pixelstore.c
@@ -214,7 +214,7 @@ _mesa_PixelStorei( GLenum pname, GLint param )
void GLAPIENTRY
_mesa_PixelStoref( GLenum pname, GLfloat param )
{
- _mesa_PixelStorei( pname, (GLint) param );
+ _mesa_PixelStorei( pname, IROUND(param) );
}
Maybe tag this as a candidate for the 7.11 branch (though it's pretty
obscure).
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] implicit declaration of function wl_drm_create
2011/10/18 chris wwzbw...@163.com: Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? Seems like you're compiling mesa 7.11 again wayland master, but they are incompatible. The wl_drm_create function is no longer generated from the protocol file, wl_display_bind has to be used with current wayland, and there are other incompatibilities. You should use mesa from git instead. (You could also try whether mesa 7.11 builds/runs fine against the wayland 0.8 branch. But I'm not sure if thats working, and if its still legacy stuff your using then.. I'd really suggest to use mesa master instead.) ___ 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] Fixed function fragment shader to GLSL
On Tue, 18 Oct 2011 11:39:16 -0700 (PDT), Jakob Bornecrantz ja...@vmware.com wrote: - Original Message - Here's this patch series again, part of the kill-Mesa-IR goal we have for next release. It's been no regressions for me for a while, I was just trying to track down a 2% performance regression on gen6. It turns out that on my gen4 system, it's no performance regression, and on gen7 (at least according to testing with the followon patches to use the new coegen), it's a ~4% performance win. While many things were learned in the process, the cause of the 2% loss appears to come down to some GPU instruction pipelining issue with lots of handwaving on my part. When using the new backend, we generate like 1/3 fewer instructions (after accounting for the 8/16 compile). I'm not including the patches for using the new backend quite yet, as there's a functional regression on gm45 in the new backend that I need to track down first. Hi, I know I told you to wait till Monday but I didn't get around to take a look at the changes, sorry about that, tho I would have appreciated that you at least pinged me before you pushed the changes. After a far-longer-than-reasonably-required review timeframe, you asked me to delay even longer and made a commitment to review by then. You failed at that commitment. It's been 9 months in which if you actually cared you would have done something. You didn't. While you say tested the changes I assume you didn't test any Gallium driver (which you probably should since the only real driver in use today that isn't Gallium is i965). Wrong. I tested and fixed softpipe for you (broken GLSL support), after waiting a long time for you to do it. I'm also assuming this patch series will have the previous set of regressions as I outlined the last time this was up for discussion. http://article.gmane.org/gmane.comp.video.mesa3d.devel/24837 No, because other optimization passes were added in the meantime, because GLSL codegen matters. Apps are using GLSL now. If there are still regressions in codegen quality from this change, that's highlighting that your GLSL support has issues that affect apps and should be fixed, not that this change is broken. (However, last time I tested, glean texcombine is actually emitting fewer Mesa IR instructions now than it did before the change. So there likely isn't even any problem). Also I would appreciated these kind of change the whole world changes to have a larger Acked-by/Reviewed-by base the just one other guy using the same test set as the author. I look forward to your patches making improvements. pgpcIaWS8HsL3.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] More shader API internal house cleaning
On 10/07/2011 05:06 PM, Ian Romanick wrote: This should be the last batch of internal clean-ups before the real work. I should be able to send some cleaned up uniform rework patches (as discuessed at XDC last month) next week. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Patches 1-5 look good to me. It wasn't quite clear to me how you managed to avoid the sorting (or what it was for), but I understand your next series is wiping this and making it more robust obvious anyway...so I'm fine with it. Reviewed-by: Kenneth Graunke kenn...@whitecape.org I'm not planning on reviewing patch 6 since Bryan already did and I figure it's pretty similar to 5 anyway. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: setup address rounding enable bits
On Mon, 17 Oct 2011 11:52:05 +0800, Yuanhan Liu yuanhan@linux.intel.com wrote: On Sat, Oct 15, 2011 at 08:59:52AM +0800, Liu Aleaxander wrote: On Sat, Oct 15, 2011 at 2:11 AM, Eric Anholt e...@anholt.net wrote: On Thu, 13 Oct 2011 11:34:34 +0800, Yuanhan Liu yuanhan@linux.intel.com wrote: The patch(based on the reading of the emulator) came from while I was trying to fix the oglc pbo texImage.1PBODefaults fail. This case generates a texture with the width and height equal to window's width and height respectively, then try to texture it on the whole window. So, it's exactly one texel for one pixel. And, the min filter and mag filter are GL_LINEAR. It runs with swrast OK, as expected. But it failed with i965 driver. Well, you can't tell the difference from the screen, as the error is quite tiny. From my digging, it seems that there are some tiny error happened while getting tex address. This will break the one texel for one pixel rule in this case. Thus the linear result is taken, with tiny error. This patch would fix several oglc pbo subcase fail on both ILK, SNB and IVB. I would really like to see a piglit test for 1:1 linear-filtered texturing being precise, like apparently you found in oglconform. It's important to compositor developers. Will try to write one next week. Patch sent. BTW, I don't have the piglit git write access. Eric, would you please help me to get the access? You have piglit write access now. I didn't have much comment on the patch because the docs on the bits weren't really clear on what they did. But if it fixes the piglit testcase and doesn't regress other things, I'd say go for it. pgpvAn4wW33Cj.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Skip mipmap generation if there is no source image.
The spec doesn't explicitly mandate this behavior, but it seems like
the only sensible thing to do (as opposed to assertion failing or
segfaulting).
v2: Do the early return before calling into the driver function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40308
---
src/mesa/main/fbobject.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index f9da54e..c56062a 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2486,6 +2486,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
void GLAPIENTRY
_mesa_GenerateMipmapEXT(GLenum target)
{
+ struct gl_texture_image *srcImage;
struct gl_texture_object *texObj;
GLboolean error;
@@ -2532,6 +2533,13 @@ _mesa_GenerateMipmapEXT(GLenum target)
}
_mesa_lock_texture(ctx, texObj);
+
+ srcImage = _mesa_select_tex_image(ctx, texObj, target, texObj-BaseLevel);
+ if (!srcImage) {
+ _mesa_unlock_texture(ctx, texObj);
+ return;
+ }
+
if (target == GL_TEXTURE_CUBE_MAP) {
GLuint face;
for (face = 0; face 6; face++)
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Set MaxIfDepth to UINT_MAX on Gen6+ and 16 on prior generations.
Commit 488fe51cf823ccd137c667f1e92dd86f8323b723 converted the EmitNoIfs
flag to MaxIfDepth, an unsigned integer saying flatten if-statements
nested beyond this depth.
Unfortunately, i965 left this initialized to 0, which made ir_to_mesa
attempt to flatten all if-statements. We didn't notice right away
because we usually throw away ir_to_mesa's code in favor of the native
VS and FS backends...but this still creates a lot of unnecessary work.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Bryan Cain bryanca...@gmail.com
Cc: Ian Romanick i...@freedesktop.org
---
src/mesa/drivers/dri/i965/brw_context.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index c1b274f..95662dc 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -116,6 +116,7 @@ brwCreateContext(int api,
/* We want the GLSL compiler to emit code that uses condition codes */
for (i = 0; i = MESA_SHADER_FRAGMENT; i++) {
+ ctx-ShaderCompilerOptions[i].MaxIfDepth = intel-gen 6 ? 16 :
UINT_MAX;
ctx-ShaderCompilerOptions[i].EmitCondCodes = true;
ctx-ShaderCompilerOptions[i].EmitNVTempInitialization = true;
ctx-ShaderCompilerOptions[i].EmitNoNoise = true;
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: Short-circuit lower_if_to_cond_assign when MaxIfDepth is UINT_MAX.
Setting MaxIfDepth to UINT_MAX effectively means don't lower anything.
Explicitly checking for this common case allows us to avoid walking the
IR, computing nesting levels, and so on.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Bryan Cain bryanca...@gmail.com
Cc: Ian Romanick i...@freedesktop.org
---
src/glsl/lower_if_to_cond_assign.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/glsl/lower_if_to_cond_assign.cpp
b/src/glsl/lower_if_to_cond_assign.cpp
index 7b89a15..2c5d561 100644
--- a/src/glsl/lower_if_to_cond_assign.cpp
+++ b/src/glsl/lower_if_to_cond_assign.cpp
@@ -79,6 +79,9 @@ public:
bool
lower_if_to_cond_assign(exec_list *instructions, unsigned max_depth)
{
+ if (max_depth == UINT_MAX)
+ return false;
+
ir_if_to_cond_assign_visitor v(max_depth);
visit_list_elements(v, instructions);
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] glapi: Add Uniform Buffer Object API
On Mon, 17 Oct 2011 00:37:14 +0200, vlj v...@ovi.com wrote: --- src/mapi/glapi/gen/ARB_Uniform_Buffer_Object.xml | 115 ++ src/mapi/glapi/gen/Makefile |1 + src/mapi/glapi/gen/gl_API.xml|2 +- 3 files changed, 117 insertions(+), 1 deletions(-) create mode 100644 src/mapi/glapi/gen/ARB_Uniform_Buffer_Object.xml diff --git a/src/mapi/glapi/gen/ARB_Uniform_Buffer_Object.xml b/src/mapi/glapi/gen/ARB_Uniform_Buffer_Object.xml new file mode 100644 index 000..ea9d6b7 +function name=GetActiveUniformsiv offset=assign +param name=program type=GLuint / +param name=uniformCount type=GLsizei / +param name=uniformIndices type=const GLuint* / +param name=pname type=GLenum / +param name=paras type=GLint* / Didn't actually review this patch, but saw this typo while scrolling down. +/function pgprkNcENuKaE.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] mesa : advertise GL_ARB_Uniform_Buffer_Object extension
On Mon, 17 Oct 2011 00:37:16 +0200, vlj v...@ovi.com wrote:
---
src/glsl/glsl_lexer.ll |3 ++-
src/glsl/glsl_parser_extras.cpp |1 +
src/glsl/glsl_parser_extras.h |2 ++
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index cfd8926..a091f62 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -260,7 +260,8 @@ layout{
if ((yyextra-language_version = 140)
|| yyextra-AMD_conservative_depth_enable
|| yyextra-ARB_explicit_attrib_location_enable
- || yyextra-ARB_fragment_coord_conventions_enable) {
+ || yyextra-ARB_fragment_coord_conventions_enable
+ || yyextra-ARB_uniform_buffer_object_enable) {
return LAYOUT_TOK;
} else {
yylval-identifier = strdup(yytext);
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 8f740e6..61e3933 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -265,6 +265,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
EXT(AMD_conservative_depth, true, false, true, true, false,
AMD_conservative_depth),
EXT(AMD_shader_stencil_export, false, false, true, true, false,
ARB_shader_stencil_export),
EXT(OES_texture_3D, true, false, true, false, true,
EXT_texture3D),
+ EXT(ARB_uniform_buffer_object, true, false, true, true, false,
dummy_true),
};
UBOs should require driver support, so you can't just always say it's
enabled. And certainly not as the second patch of a series to add
support for the extension.
pgpYu2ufjI59s.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/9] glsl: parser now aware of UBO
This patch is inconsistent with whitespace compared to surrounding code. I won't review it further. pgp98yoP1zVu0.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] intel: Add function intel_renderbuffer_hiz_alloc
On Mon, 17 Oct 2011 07:40:27 -0700, Chad Versace c...@chad-versace.us wrote:
This function allocates the HiZ region and initializes the HiZ control
state for a depthbuffer.
It is wise to define the logic for HiZ region allocation in a single
location, since when MSAA arrives that logic will become more complicated.
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/mesa/drivers/dri/intel/intel_fbo.c | 21 +
src/mesa/drivers/dri/intel/intel_fbo.h |8
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index b7cfdb9..17397e1 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -110,6 +110,27 @@ intel_framebuffer_get_hiz_region(struct gl_framebuffer
*fb)
return NULL;
}
+bool
+intel_renderbuffer_alloc_hiz(struct intel_context *intel,
+ struct intel_renderbuffer *depth_irb)
+{
+ struct intel_region *depth_region = depth_irb-region;
+ struct intel_hiz_control *hiz = depth_irb-region-hiz;
+
+ hiz-region = intel_region_alloc(intel-intelScreen,
+ I915_TILING_Y,
+ depth_region-cpp,
+ depth_region-width,
+ depth_region-height,
+ GL_TRUE);
+ if (!hiz-region)
+ return false;
+
+ hiz-need_resolve = INTEL_HIZ_NEED_NO_RESOLVE;
+ hiz-depth_format = depth_irb-Base.Format;
+ return true;
+}
The region is supposed to be a fraction of the depth region's height,
right?
pgpSCWstb55CU.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Skip mipmap generation if there is no source image.
On 10/18/2011 04:09 PM, Eric Anholt wrote:
The spec doesn't explicitly mandate this behavior, but it seems like
the only sensible thing to do (as opposed to assertion failing or
segfaulting).
v2: Do the early return before calling into the driver function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40308
---
src/mesa/main/fbobject.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index f9da54e..c56062a 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2486,6 +2486,7 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
void GLAPIENTRY
_mesa_GenerateMipmapEXT(GLenum target)
{
+ struct gl_texture_image *srcImage;
struct gl_texture_object *texObj;
GLboolean error;
@@ -2532,6 +2533,13 @@ _mesa_GenerateMipmapEXT(GLenum target)
}
_mesa_lock_texture(ctx, texObj);
+
+ srcImage = _mesa_select_tex_image(ctx, texObj, target, texObj-BaseLevel);
+ if (!srcImage) {
+ _mesa_unlock_texture(ctx, texObj);
+ return;
+ }
+
if (target == GL_TEXTURE_CUBE_MAP) {
GLuint face;
for (face = 0; face 6; face++)
Reviewed-by: Brian Paul bri...@vmware.com
BTW, for anyone else reading along, the earlier _mesa_cube_complete()
test (if it passes) will ensure that checking just the positive-X face
image is sufficient for cubemaps.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] intel: Remove intel_renderbuffer::hiz_region
On Mon, 17 Oct 2011 07:40:28 -0700, Chad Versace c...@chad-versace.us wrote:
Replace it with intel_renderbuffer::region::hiz::region.
Signed-off-by: Chad Versace c...@chad-versace.us
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 27 +
src/mesa/drivers/dri/intel/intel_context.c | 10 --
src/mesa/drivers/dri/intel/intel_fbo.c | 36 +--
src/mesa/drivers/dri/intel/intel_fbo.h |3 --
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |1 -
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 14 -
6 files changed, 29 insertions(+), 62 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 2e6780b..6b521e0 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -583,21 +574,10 @@ intel_update_tex_wrapper_regions(struct intel_context
*intel,
/* Allocate the texture's hiz region if necessary. */
if (intel-vtbl.is_hiz_depth_format(intel, rb-Format)
-!intel_image-mt-hiz_region) {
- intel_image-mt-hiz_region =
- intel_region_alloc(intel-intelScreen,
-I915_TILING_Y,
-_mesa_get_format_bytes(rb-Format),
-rb-Width,
-rb-Height,
-GL_TRUE);
- if (!intel_image-mt-hiz_region)
- return GL_FALSE;
- }
-
- /* Point the renderbuffer's hiz region to the texture's hiz region. */
- if (irb-hiz_region != intel_image-mt-hiz_region) {
- intel_region_reference(irb-hiz_region, intel_image-mt-hiz_region);
+irb-region-hiz.region == NULL) {
+ bool ok = intel_renderbuffer_alloc_hiz(intel, irb);
+ if (!ok)
+ return false;
}
I think you're aware of this already, but just in case:
The hiz region allocated here using the new rb_alloc_hiz looks like it
will be based on the size of the whole texture miptree (since it looks
up the region's size, not rb w/h), while all that should be needed is
the maximum size of any texture image.
I think we could just use Width/Height, if we resolved at
FinishRenderTexture time and freed the renderbuffer's hiz region (which
I think would be reasonable for now, and should make mipmapped depth hiz
pretty straightforward).
pgp38MRob35Mx.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] i965: Fix incorrect dirty bit in gen6_prepare_wm_push_constants.
We definitely want CACHE_NEW_WM_PROG, not CACHE_NEW_VS_PROG.
NOTE: This is a candidate for the 7.11 branch.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen6_wm_state.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index 00fadb9..370516d 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -49,7 +49,7 @@ gen6_prepare_wm_push_constants(struct brw_context *brw)
/* XXX: Should this happen somewhere before to get our state flag set? */
_mesa_load_state_parameters(ctx, fp-program.Base.Parameters);
- /* CACHE_NEW_VS_PROG */
+ /* CACHE_NEW_WM_PROG */
if (brw-wm.prog_data-nr_params != 0) {
float *constants;
unsigned int i;
@@ -85,7 +85,7 @@ const struct brw_tracked_state gen6_wm_constants = {
.mesa = _NEW_PROGRAM_CONSTANTS,
.brw = (BRW_NEW_BATCH |
BRW_NEW_FRAGMENT_PROGRAM),
- .cache = CACHE_NEW_VS_PROG,
+ .cache = CACHE_NEW_WM_PROG,
},
.prepare = gen6_prepare_wm_push_constants,
};
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965: Use AUB_TRACE_WM_CONSTANTS in gen7_prepare_wm_push_constants.
This makes it match gen6_prepare_wm_push_constants. For some reason, it had been using AUB_TRACE_NO_TYPE. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/gen7_wm_state.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c b/src/mesa/drivers/dri/i965/gen7_wm_state.c index 55a603e..b63776f 100644 --- a/src/mesa/drivers/dri/i965/gen7_wm_state.c +++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c @@ -51,7 +51,7 @@ gen7_prepare_wm_constants(struct brw_context *brw) float *constants; unsigned int i; - constants = brw_state_batch(brw, AUB_TRACE_NO_TYPE, + constants = brw_state_batch(brw, AUB_TRACE_WM_CONSTANTS, brw-wm.prog_data-nr_params * sizeof(float), 32, brw-wm.push_const_offset); -- 1.7.7 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965: Remove copy and pasted gen7_wm_constants state atom.
Now that this is identical to gen6_wm_constants, just use that instead.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_state_upload.c |2 +-
src/mesa/drivers/dri/i965/gen7_wm_state.c| 55 --
2 files changed, 1 insertions(+), 56 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 24e83ff..5374806 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -200,7 +200,7 @@ const struct brw_tracked_state *gen7_atoms[] =
brw_vs_constants, /* Before vs_surfaces and constant_buffer */
brw_wm_constants, /* Before wm_surfaces and constant_buffer */
gen6_vs_constants, /* Before vs_state */
- gen7_wm_constants, /* Before wm_surfaces and constant_buffer */
+ gen6_wm_constants, /* Before wm_surfaces and constant_buffer */
brw_vs_surfaces, /* must do before unit */
gen7_wm_constant_surface, /* must do before wm surfaces/bind bo */
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index b63776f..653f6a8 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -32,61 +32,6 @@
#include intel_batchbuffer.h
static void
-gen7_prepare_wm_constants(struct brw_context *brw)
-{
- struct intel_context *intel = brw-intel;
- struct gl_context *ctx = intel-ctx;
- /* BRW_NEW_FRAGMENT_PROGRAM */
- const struct brw_fragment_program *fp =
- brw_fragment_program_const(brw-fragment_program);
-
- /* Updates the ParameterValues[i] pointers for all parameters of the
-* basic type of PROGRAM_STATE_VAR.
-*/
- /* XXX: Should this happen somewhere before to get our state flag set? */
- _mesa_load_state_parameters(ctx, fp-program.Base.Parameters);
-
- /* CACHE_NEW_WM_PROG */
- if (brw-wm.prog_data-nr_params != 0) {
- float *constants;
- unsigned int i;
-
- constants = brw_state_batch(brw, AUB_TRACE_WM_CONSTANTS,
- brw-wm.prog_data-nr_params *
- sizeof(float),
- 32, brw-wm.push_const_offset);
-
- for (i = 0; i brw-wm.prog_data-nr_params; i++) {
-constants[i] = convert_param(brw-wm.prog_data-param_convert[i],
- brw-wm.prog_data-param[i]);
- }
-
- if (0) {
-printf(WM constants:\n);
-for (i = 0; i brw-wm.prog_data-nr_params; i++) {
- if ((i 7) == 0)
- printf(g%d: , brw-wm.prog_data-first_curbe_grf + i / 8);
- printf(%8f , constants[i]);
- if ((i 7) == 7)
- printf(\n);
-}
-if ((i 7) != 0)
- printf(\n);
-printf(\n);
- }
- }
-}
-
-const struct brw_tracked_state gen7_wm_constants = {
- .dirty = {
- .mesa = _NEW_PROGRAM_CONSTANTS,
- .brw = (BRW_NEW_BATCH | BRW_NEW_FRAGMENT_PROGRAM),
- .cache = CACHE_NEW_WM_PROG,
- },
- .prepare = gen7_prepare_wm_constants,
-};
-
-static void
upload_wm_state(struct brw_context *brw)
{
struct intel_context *intel = brw-intel;
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Fix gl_NormalMatrix swizzle setup to match i965's invariants.
A driver trying to set up builtin uniforms is faced with a problem:
How do I walk the ir_variable structure (representing an array of
structs, or array of matrices, or struct, or whatever), and set up
driver structures so that dereference of that uniform gets the
corresponding ParameterValues[] entry. The rule in general is that
each corresponding vector-sized field of an array of structs is one
builtin uniform state slot. i965 relied on another invariant: each
state slot has a number of unique channel swizzles corresponding to
the number of elements in the field's vector, to avoid needing to walk
the glsl_type in parallel to get at vector_elements.
All of the builtin uniforms followed this behavior, except for
gl_NormalMatrix. That's a mat3 (so 3 vec3s), but it was swizzled as 3
vec4s.
Fixes piglit glsl-fs-normalmatrix.
---
src/glsl/ir_variable.cpp |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ir_variable.cpp b/src/glsl/ir_variable.cpp
index 6ae3b1f..42c01e0 100644
--- a/src/glsl/ir_variable.cpp
+++ b/src/glsl/ir_variable.cpp
@@ -232,11 +232,11 @@ MATRIX(gl_TextureMatrixInverseTranspose,
static struct gl_builtin_uniform_element gl_NormalMatrix_elements[] = {
{ NULL, { STATE_MODELVIEW_MATRIX, 0, 0, 0, STATE_MATRIX_INVERSE},
- SWIZZLE_XYZW },
+ MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y, SWIZZLE_Z, SWIZZLE_Z) },
{ NULL, { STATE_MODELVIEW_MATRIX, 0, 1, 1, STATE_MATRIX_INVERSE},
- SWIZZLE_XYZW },
+ MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y, SWIZZLE_Z, SWIZZLE_Z) },
{ NULL, { STATE_MODELVIEW_MATRIX, 0, 2, 2, STATE_MATRIX_INVERSE},
- SWIZZLE_XYZW },
+ MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y, SWIZZLE_Z, SWIZZLE_Z) },
};
#undef MATRIX
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Fix and cleaned up testcase
There was stuff in the testcase that looked quite unusual (red instead of green for success, not showing all the results at once, etc.) for a piglit test, so I hacked up the testcase quite a bit. It was an interesting bug, and luckily an easy little fix. I'd love to get your review/ack on the testcase changes, and hopefully someone else can look at the Mesa change. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl-fs-normalmatrix: New test program for gl_NormalMatrix.
From: tom fogal tfo...@sci.utah.edu
v2: lots of hacking by anholt to make it look more like a normal
piglit test and make all results visible at once.
---
tests/all.tests |1 +
tests/shaders/CMakeLists.gl.txt |1 +
tests/shaders/glsl-fs-normalmatrix.c | 166 ++
3 files changed, 168 insertions(+), 0 deletions(-)
create mode 100644 tests/shaders/glsl-fs-normalmatrix.c
diff --git a/tests/all.tests b/tests/all.tests
index 0248164..89bd03d 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -396,6 +396,7 @@ add_plain_test(shaders, 'glsl-fs-loop')
add_plain_test(shaders, 'glsl-fs-loop-nested')
add_plain_test(shaders, 'glsl-fs-mix')
add_plain_test(shaders, 'glsl-fs-mix-constant')
+add_concurrent_test(shaders, 'glsl-fs-normalmatrix')
add_plain_test(shaders, 'glsl-fs-pointcoord')
add_plain_test(shaders, 'glsl-fs-raytrace-bug27060')
add_plain_test(shaders, 'glsl-fs-sampler-numbering')
diff --git a/tests/shaders/CMakeLists.gl.txt b/tests/shaders/CMakeLists.gl.txt
index 3dce256..ed72b21 100644
--- a/tests/shaders/CMakeLists.gl.txt
+++ b/tests/shaders/CMakeLists.gl.txt
@@ -82,6 +82,7 @@ add_executable (glsl-fs-loop glsl-fs-loop.c)
add_executable (glsl-fs-loop-nested glsl-fs-loop-nested.c)
add_executable (glsl-fs-mix glsl-fs-mix.c)
add_executable (glsl-fs-mix-constant glsl-fs-mix-constant.c)
+add_executable (glsl-fs-normalmatrix glsl-fs-normalmatrix.c)
IF (NOT MSVC)
add_executable (glsl-fs-raytrace-bug27060 glsl-fs-raytrace-bug27060.c)
ENDIF (NOT MSVC)
diff --git a/tests/shaders/glsl-fs-normalmatrix.c
b/tests/shaders/glsl-fs-normalmatrix.c
new file mode 100644
index 000..b55a80a
--- /dev/null
+++ b/tests/shaders/glsl-fs-normalmatrix.c
@@ -0,0 +1,166 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Tom Fogal
+ *
+ */
+
+/** @file glsl-fs-normalmatrix.c
+ *
+ * Tests gl_NormalMatrix for appropriate initial values.
+ */
+
+#include piglit-util.h
+
+int piglit_width = 30, piglit_height = 30;
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+static const char vert[] = {
+ void main()\n
+ {\n
+ gl_Position = ftransform();\n
+ }\n
+};
+
+/* Creates a fragment shader which colors everything green if
+ * gl_NormalMatrix[col].row
+ * is between 'low' and 'high', otherwise everything is red.
+ * The returned string is dynamically allocated and must be free'd by the
+ * caller.
+ */
+static char *
+generate_fs(int row, int col)
+{
+ static const char *fs_template =
+ void main()\n
+ {\n
+ if (%f = gl_NormalMatrix[%u].%c \n
+ gl_NormalMatrix[%u].%c = %f)\n
+ gl_FragColor = vec4(0.0, 1.0, 0.0, 0.0);\n
+ else\n
+ gl_FragColor = vec4(1.0, 0.0, 0.0, 0.0);\n
+ }\n;
+ char *result;
+ char row_char = xyz[row];
+ float expected_matrix[] = {
+ 1, 0, 0,
+ 0, 1, 0,
+ 0, 0, 1,
+ };
+ float expected = expected_matrix[row * 3 + col];
+ float low = expected - .01;
+ float high = expected + .01;
+
+ if (0) {
+ printf(test: %g = gl_NormalMatrix[%u].%c = %g\n,
+ low, col, row_char, high);
+ }
+
+ result = calloc(1, strlen(fs_template) + 100);
+ sprintf(result, fs_template, low, col, row_char, col, row_char, high);
+
+ return result;
+}
+
+static bool
+test(int row, int col)
+{
+ GLint vs, fs, prog;
+ float green[] = {0.0, 1.0, 0.0, 0.0};
+ char *fs_source;
+ bool pass;
+ int w = piglit_width / 3;
+ int h = piglit_height / 3;
+ int x = col * w;
+ int y = (2 - row) * h;
+
+ fs_source = generate_fs(row, col);
+ vs = piglit_compile_shader_text(GL_VERTEX_SHADER,
[Mesa-dev] [PATCH 1/2] i965: silence signed/unsigned comparison warning
From: Brian Paul bri...@vmware.com
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index e003020..0ea6d31 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1549,7 +1549,8 @@ vec4_visitor::try_rewrite_rhs_to_dst(ir_assignment *ir,
* potentially reswizzle the operands of many instructions so that
* we could handle out of order channels, but don't yet.
*/
- for (int i = 0; i 4; i++) {
+
+ for (unsigned i = 0; i 4; i++) {
if (dst.writemask (1 i)) {
if (!(last_rhs_inst-dst.writemask (1 i)))
return false;
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: use a cast to silence a signed/unsigned comparison warning
From: Brian Paul bri...@vmware.com --- .../drivers/dri/i965/brw_vec4_reg_allocate.cpp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp index 1ace91f..6de7682 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp @@ -217,7 +217,7 @@ vec4_visitor::reg_allocate() int reg = ra_get_node_reg(g, i); hw_reg_mapping[i] = first_assigned_grf + brw-vs.ra_reg_to_grf[reg]; - prog_data-total_grf = MAX2(prog_data-total_grf, + prog_data-total_grf = MAX2((int) prog_data-total_grf, hw_reg_mapping[i] + virtual_grf_sizes[i]); } -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] implicit declaration of function wl_drm_create
Dear Kristian, I have found no drm.xml in mesa code. Do you means wayland-drm.xml under src/egl/wayland/wayland-drm/protocol. At 2011-10-18 23:55:18,Kristian Høgsberg k...@bitplanet.net wrote: 2011/10/18 chris wwzbw...@163.com: Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? It's defined in the code generated from the drm.xml definition. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] implicit declaration of function wl_drm_create
It's in wayland's source code. -Original Message- From: mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org [mailto:mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org] On Behalf Of chris Sent: Wednesday, October 19, 2011 10:48 AM To: Kristian Høgsberg Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] implicit declaration of function wl_drm_create Dear Kristian, I have found no drm.xml in mesa code. Do you means wayland-drm.xml under src/egl/wayland/wayland-drm/protocol. At 2011-10-18 23:55:18,Kristian Høgsberg k...@bitplanet.net wrote: 2011/10/18 chris wwzbw...@163.com: Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? It's defined in the code generated from the drm.xml definition. Kristian ___ 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] mesa: handle PBO access error in display list mode
Simply generate GL_INVALID_OPERATION error at display list mode. As explained by Brian, we are going to access PBO data at compile time. No need to defer the error at execution time. Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com --- src/mesa/main/dlist.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c index 625649e..d901bdd 100644 --- a/src/mesa/main/dlist.c +++ b/src/mesa/main/dlist.c @@ -939,7 +939,9 @@ unpack_image(struct gl_context *ctx, GLuint dimensions, } return image; } + /* bad access! */ + _mesa_error(ctx, GL_INVALID_OPERATION, invalid PBO access); return NULL; } -- 1.7.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa: handle PBO access error in display list mode
On Mon, Oct 17, 2011 at 08:24:38AM -0600, Brian Paul wrote: On 10/15/2011 08:05 PM, Liu Aleaxander wrote: From 98d4600d74829d16045dd577855b7c9f25e762c2 Mon Sep 17 00:00:00 2001 From: Yuanhan Liuyuanhan@linux.intel.com Date: Sun, 16 Oct 2011 09:13:10 +0800 Subject: [PATCH] mesa: handle PBO access error in display list mode While dealing with pbo data in display list mode, it does check the pbo access error at unpack_image. But it could not generate it, as it is in display list compile time. If invalid PBO access found, NULL then would be returned. While at the execution time, we can't detect if we met a such error as the data is not stored as PBO access anymore. The code would treat it as a _normal_ NULL pixel data. That's how the error is missed. Here I introduced a in-file macro BAD_ACCESS to mark that we meet a PBO access error at compile time, and we would like to handle it at the execution time. This would make the error defer recognizable. I think we should just generate the INVALID_OPERATION error at display list compilation time. If a glDrawPixels() command is being compiled and its data is coming from a PBO, we'll access the PBO data at compile time, not execution time. If we encounter an error when we're doing that, we should generate the error right away. Thanks for the info. The ARB_pbo spec says: If a pixel unpack buffer object is bound and unpacking the pixel data according to the process described below would access memory beyond the size of the pixel unpack buffer's memory size, INVALID_OPERATION results. I think if the intention was to generate the error later during execution, the spec would have said so. Have you found spec language to indicate otherwise? Nope, I just thought we should handle the error at execution time but not compile time. Updated patch sent. Thanks, Yuanhan Liu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] implicit declaration of function wl_drm_create
Oops, yes i use the wrong branch of 7.11rc4 from git repository. After pull the newest version, it is compiled succesfully. wl_drm_create is removed since this commit: commit b89bca6d8b84e7922f44258c41e37997775f98c9 Author: Chia-I Wu o...@lunarg.com Date: Wed Sep 7 21:42:56 2011 +0800 st/egl: track server side wayland changes Follow changes in c661ecce1089000c3fca9a543713f8264221be50. Now the mesa code seems compatible with the wayland 0.8. Thank you Benjamin At 2011-10-19 04:53:16,Benjamin Franzke benjaminfran...@googlemail.com wrote: 2011/10/18 chris wwzbw...@163.com: Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? Seems like you're compiling mesa 7.11 again wayland master, but they are incompatible. The wl_drm_create function is no longer generated from the protocol file, wl_display_bind has to be used with current wayland, and there are other incompatibilities. You should use mesa from git instead. (You could also try whether mesa 7.11 builds/runs fine against the wayland 0.8 branch. But I'm not sure if thats working, and if its still legacy stuff your using then.. I'd really suggest to use mesa master instead.) ___ 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] implicit declaration of function wl_drm_create
I think you'd like this file: To be more concrete: mesa/src/egl/wayland/wayland-drm/wayland-drm.xml -Original Message- From: mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org [mailto:mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org] On Behalf Of Zhao, Juan J Sent: Wednesday, October 19, 2011 11:05 AM To: 'chris'; 'Kristian Høgsberg' Cc: 'mesa-dev@lists.freedesktop.org' Subject: Re: [Mesa-dev] implicit declaration of function wl_drm_create It's in wayland's source code. -Original Message- From: mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org [mailto:mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org] On Behalf Of chris Sent: Wednesday, October 19, 2011 10:48 AM To: Kristian Høgsberg Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] implicit declaration of function wl_drm_create Dear Kristian, I have found no drm.xml in mesa code. Do you means wayland-drm.xml under src/egl/wayland/wayland-drm/protocol. At 2011-10-18 23:55:18,Kristian Høgsberg k...@bitplanet.net wrote: 2011/10/18 chris wwzbw...@163.com: Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? It's defined in the code generated from the drm.xml definition. Kristian ___ 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
