Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On Thu, 31 May 2012 16:19:17 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
Tungsten Graphics has not existed for several years, and the majority of
ongoing development and support is done by Intel. I chose to include
Open Source Technology Center to distinguish it from, say, the closed
source Windows OpenGL driver.
The one downside to this patch is that applications that pattern match
against Intel may start applying workarounds meant for the Windows
driver. However, it does seem like the right thing to do.
This does change oglconform behavior.
Acked-by: Eric Anholt e...@anholt.net
Acked-by: Ian Romanick ian.d.roman...@intel.com
Cc: Eugeni Dodonov eug...@dodonov.net
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/intel/intel_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 9deb4ca..712acb8 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -72,7 +72,7 @@ intelGetString(struct gl_context * ctx, GLenum name)
switch (name) {
case GL_VENDOR:
- return (GLubyte *) Tungsten Graphics, Inc;
+ return (GLubyte *) Intel® Open Source Technology Center;
Hi,
that is an utf-8 character there, right?
Is that really appropriate, given the API and all?
I don't know about character encoding stuff, but that looks surprising.
Just wondering...
Thanks,
pq
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On Fri, 1 Jun 2012 09:18:44 +0300
Pekka Paalanen ppaala...@gmail.com wrote:
On Thu, 31 May 2012 16:19:17 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
Tungsten Graphics has not existed for several years, and the majority of
ongoing development and support is done by Intel. I chose to include
Open Source Technology Center to distinguish it from, say, the closed
source Windows OpenGL driver.
The one downside to this patch is that applications that pattern match
against Intel may start applying workarounds meant for the Windows
driver. However, it does seem like the right thing to do.
This does change oglconform behavior.
Acked-by: Eric Anholt e...@anholt.net
Acked-by: Ian Romanick ian.d.roman...@intel.com
Cc: Eugeni Dodonov eug...@dodonov.net
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/intel/intel_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 9deb4ca..712acb8 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -72,7 +72,7 @@ intelGetString(struct gl_context * ctx, GLenum name)
switch (name) {
case GL_VENDOR:
- return (GLubyte *) Tungsten Graphics, Inc;
+ return (GLubyte *) Intel® Open Source Technology Center;
Hi,
that is an utf-8 character there, right?
Is that really appropriate, given the API and all?
I don't know about character encoding stuff, but that looks surprising.
Just wondering...
Oops, sorry, I missed the other replies. Let me rephrase:
is it ok by the GL spec to return non-ASCII strings here?
Thanks,
pq
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel(R) Open Source Technology Center.
Kenneth Graunke kenn...@whitecape.org writes:
On 05/31/2012 04:28 PM, Roland Mainz wrote:
On Fri, Jun 1, 2012 at 1:19 AM, Kenneth Graunkekenn...@whitecape.org
wrote:
switch (name) {
case GL_VENDOR:
- return (GLubyte *) Tungsten Graphics, Inc;
+ return (GLubyte *) Intel® Open Source Technology Center;
break;
Uhm... isn't ® a character outside the ASCII range ? Some compiles
might choke on this, i.e. the Sun Workshop/Forte/Studio compilers
require -xcsi (... This option allows the C compiler to accept source
code written in locales that do not conform to the ISO C source
character code requirements. These locales include ja_JP.PCK ...) to
avoid occasional hiccups.
I'm happy to change it if it's an issue, but I believe that the ®
character already appears in the source code:
case PCI_CHIP_GM45_GM:
chipset = Mobile Intel® GM45 Express Chipset;
break;
I believe the C89 specification disallows the use of characters outside
the basic character set in the source file. The basic character set
is a subset of the characters representable by ASCII. Or alternatively,
that it leaves the effect implementation-defined or maybe even
undefined. But I don't have the C89 specification lying around to
check.
I expect many compilers will accept such characters, and interpret them
according to the current locale. So what character you end up with
depends on which locale you compile in, or which locale you run the
application in. This may lead some compilers to generate warnings about
this situation.
C++03 allows those characters, but their interpretation is
implementation-defined. C++03 supports the construct '\u00a9', which
represents the unicode character U+00A9. I doubt C89 does the same.
For string literals the '\xa9' construct can be used, but its
interpretation is also implementation-defined (at least as far as
which character it represents, given that the execution character set is
implementation-defined). And keep in mind that '\xa9' must not be
followed by a hexadecimal digit.
and it definitely appears in comments.
That's less of an issue, since the compiler is quite likely to just
ignore those.
eirik
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On Fri, Jun 01, 2012 at 09:18:44AM +0300, Pekka Paalanen wrote:
On Thu, 31 May 2012 16:19:17 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
Tungsten Graphics has not existed for several years, and the majority of
ongoing development and support is done by Intel. I chose to include
Open Source Technology Center to distinguish it from, say, the closed
source Windows OpenGL driver.
The one downside to this patch is that applications that pattern match
against Intel may start applying workarounds meant for the Windows
driver. However, it does seem like the right thing to do.
This does change oglconform behavior.
Acked-by: Eric Anholt e...@anholt.net
Acked-by: Ian Romanick ian.d.roman...@intel.com
Cc: Eugeni Dodonov eug...@dodonov.net
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/intel/intel_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 9deb4ca..712acb8 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -72,7 +72,7 @@ intelGetString(struct gl_context * ctx, GLenum name)
switch (name) {
case GL_VENDOR:
- return (GLubyte *) Tungsten Graphics, Inc;
+ return (GLubyte *) Intel® Open Source Technology Center;
Hi,
that is an utf-8 character there, right?
Is that really appropriate, given the API and all?
I don't know about character encoding stuff, but that looks surprising.
Just wondering...
Furthermore it actually doesn't render correctly with my encodings
(en_GB and en_US: UTF-8 and ISO-8859-1, and various Finnish and Swedish
ones left out for brevity.
Okay, problem on my end, but I'm probably not the only one (or maybe I
am just an idiot who can't setup encodings correctly.)
Wouldn't Intel(R) Open Source ... be sufficient?
Thanks,
pq
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Oliver McFadden.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50422] Furmark.exe crash with wine (32 bits under 64 bits) with llvm-3.1 and r600-llvm-compiler enabled
https://bugs.freedesktop.org/show_bug.cgi?id=50422 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/Gallium/r600 -- 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] glsl/builtins: Fix textureGrad() for Array samplers.
We were incorrectly assuming that the coordinate's dimensionality is equal to the gradient's dimensionality. For array types, the coordinate has one more component. Fixes 12 subcases of oglconform's glsl-bif-tex-grad test. NOTE: This is a candidate for stable release branches. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/builtins/tools/texture_builtins.py |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/glsl/builtins/tools/texture_builtins.py b/src/glsl/builtins/tools/texture_builtins.py index 84a144e..94971bc 100755 --- a/src/glsl/builtins/tools/texture_builtins.py +++ b/src/glsl/builtins/tools/texture_builtins.py @@ -56,7 +56,7 @@ def get_txs_dim(sampler_type): def generate_sigs(g, tex_inst, sampler_type, variant = 0, unused_fields = 0): coord_dim = get_coord_dim(sampler_type) extra_dim = get_extra_dim(sampler_type, variant Proj, unused_fields) -offset_dim = get_sampler_dim(sampler_type) +sampler_dim = get_sampler_dim(sampler_type) if variant Single: return_type = float @@ -76,12 +76,12 @@ def generate_sigs(g, tex_inst, sampler_type, variant = 0, unused_fields = 0): elif ((tex_inst == txf or tex_inst == txs) and Buffer not in sampler_type and Rect not in sampler_type): print \n (declare (in) int lod), elif tex_inst == txd: -grad_type = vec_type(, coord_dim) +grad_type = vec_type(, sampler_dim) print \n (declare (in) + grad_type + dPdx), print \n (declare (in) + grad_type + dPdy), if variant Offset: -print \n (declare (const_in) + vec_type(i, offset_dim) + offset), +print \n (declare (const_in) + vec_type(i, sampler_dim) + offset), if tex_inst == txb: print \n (declare (in) float bias), -- 1.7.10.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On 06/01/2012 09:34 AM, Pekka Paalanen wrote:
On Fri, 1 Jun 2012 09:18:44 +0300
Pekka Paalanen ppaala...@gmail.com wrote:
On Thu, 31 May 2012 16:19:17 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
Tungsten Graphics has not existed for several years, and the majority of
ongoing development and support is done by Intel. I chose to include
Open Source Technology Center to distinguish it from, say, the closed
source Windows OpenGL driver.
The one downside to this patch is that applications that pattern match
against Intel may start applying workarounds meant for the Windows
driver. However, it does seem like the right thing to do.
This does change oglconform behavior.
Acked-by: Eric Anholt e...@anholt.net
Acked-by: Ian Romanick ian.d.roman...@intel.com
Cc: Eugeni Dodonov eug...@dodonov.net
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/intel/intel_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 9deb4ca..712acb8 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -72,7 +72,7 @@ intelGetString(struct gl_context * ctx, GLenum name)
switch (name) {
case GL_VENDOR:
- return (GLubyte *) Tungsten Graphics, Inc;
+ return (GLubyte *) Intel® Open Source Technology Center;
Hi,
that is an utf-8 character there, right?
Is that really appropriate, given the API and all?
I don't know about character encoding stuff, but that looks surprising.
Just wondering...
Oops, sorry, I missed the other replies. Let me rephrase:
is it ok by the GL spec to return non-ASCII strings here?
OpenGL 3.0 spec says:
String queries return pointers to UTF-8 encoded, NULL-terminated static
strings describing properties of the current GL context.
Current GL ES specs do not define anything about the encoding.
Thanks,
pq
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
// Tapani
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Restore depth texture state on glPopAttrib(GL_TEXTURE_BIT).
According to Table 6.17 in the GL 2.1 specification, DEPTH_TEXTURE_MODE,
TEXTURE_COMPARE_MODE, and TEXTURE_COMPARE_FUNC need to be restored on
glPopAttrib(GL_TEXTURE_BIT).
Makes a number of oglconform tests happier.
v2: Make restoration conditional on the ARB_shadow and ARB_depth_texture
extensions, as suggested by Brian. I'm not sure that any
implementations still remain that don't support those, but why not?
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/attrib.c |8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index b114ec9..318d576 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -799,6 +799,14 @@ pop_texture_group(struct gl_context *ctx, struct
texture_state *texstate)
_mesa_TexParameterf(target, GL_TEXTURE_COMPARE_FAIL_VALUE_ARB,
samp-CompareFailValue);
}
+ if (ctx-Extensions.ARB_shadow) {
+_mesa_TexParameteri(target, GL_TEXTURE_COMPARE_MODE,
+samp-CompareMode);
+_mesa_TexParameteri(target, GL_TEXTURE_COMPARE_FUNC,
+samp-CompareFunc);
+ }
+ if (ctx-Extensions.ARB_depth_texture)
+_mesa_TexParameteri(target, GL_DEPTH_TEXTURE_MODE,
samp-DepthMode);
}
/* remove saved references to the texture objects */
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Implement texture buffer objects on Gen6.
Commit a07cf3397e332388d3599c83e50ac45511972890 added support for TBOs
on Gen7, but missed Gen6.
Passes piglit -t texture_buffer and oglconform's buffermapping
basic.read.texture tests.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_wm_sampler_state.c |4 ++
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 57 ++
2 files changed, 61 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c
b/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c
index 9f13299..1c61bd0 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_sampler_state.c
@@ -167,6 +167,10 @@ static void brw_update_sampler_state(struct brw_context
*brw,
struct gl_sampler_object *gl_sampler = _mesa_get_samplerobj(ctx, unit);
bool using_nearest = false;
+ /* These don't use samplers at all. */
+ if (texObj-Target == GL_TEXTURE_BUFFER)
+ return;
+
switch (gl_sampler-MinFilter) {
case GL_NEAREST:
sampler-ss0.min_filter = BRW_MAPFILTER_NEAREST;
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 6e745cf..4718337 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -645,6 +645,58 @@ brw_get_surface_num_multisamples(unsigned num_samples)
static void
+brw_update_buffer_texture_surface(struct gl_context *ctx, GLuint unit)
+{
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = brw-intel;
+ struct gl_texture_object *tObj = ctx-Texture.Unit[unit]._Current;
+ const GLuint surf_index = SURF_INDEX_TEXTURE(unit);
+ uint32_t *surf;
+ struct intel_buffer_object *intel_obj =
+ intel_buffer_object(tObj-BufferObject);
+ drm_intel_bo *bo = intel_obj ? intel_obj-buffer : NULL;
+ gl_format format = tObj-_BufferObjectFormat;
+ uint32_t brw_format = brw_format_for_mesa_format(format);
+ int texel_size = _mesa_get_format_bytes(format);
+
+ if (brw_format == 0 format != MESA_FORMAT_RGBA_FLOAT32) {
+ _mesa_problem(NULL, bad format %s for texture buffer\n,
+ _mesa_get_format_name(format));
+ }
+
+ surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
+ 6 * 4, 32, brw-wm.surf_offset[surf_index]);
+
+ surf[0] = (BRW_SURFACE_BUFFER BRW_SURFACE_TYPE_SHIFT |
+ (brw_format_for_mesa_format(format) BRW_SURFACE_FORMAT_SHIFT));
+
+ if (intel-gen = 6)
+ surf[0] |= BRW_SURFACE_RC_READ_WRITE;
+
+ if (bo) {
+ surf[1] = bo-offset; /* reloc */
+
+ /* Emit relocation to surface contents. */
+ drm_intel_bo_emit_reloc(brw-intel.batch.bo,
+ brw-wm.surf_offset[surf_index] + 4,
+ bo, 0, I915_GEM_DOMAIN_SAMPLER, 0);
+
+ int w = intel_obj-Base.Size / texel_size;
+ surf[2] = ((w 0x7f) BRW_SURFACE_WIDTH_SHIFT |
+((w 7) 0x1fff) BRW_SURFACE_HEIGHT_SHIFT);
+ surf[3] = (((w 20) 0x7f) BRW_SURFACE_DEPTH_SHIFT |
+(texel_size - 1) BRW_SURFACE_PITCH_SHIFT);
+ } else {
+ surf[1] = 0;
+ surf[2] = 0;
+ surf[3] = 0;
+ }
+
+ surf[4] = 0;
+ surf[5] = 0;
+}
+
+static void
brw_update_texture_surface( struct gl_context *ctx, GLuint unit )
{
struct brw_context *brw = brw_context(ctx);
@@ -657,6 +709,11 @@ brw_update_texture_surface( struct gl_context *ctx, GLuint
unit )
uint32_t *surf;
int width, height, depth;
+ if (tObj-Target == GL_TEXTURE_BUFFER) {
+ brw_update_buffer_texture_surface(ctx, unit);
+ return;
+ }
+
intel_miptree_get_dimensions_for_image(firstImage, width, height, depth);
surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
--
1.7.10.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Is the pure-make build system still supported?
Hi Folks, Since commit 0ce0f7c0 (mesa: Remove the generated glapi from source control, and just build it, 2012-05-15) I get this: $ make linux-x86-64 ... make[3]: Entering directory `.../src/mapi/glapi' make[3]: *** No rule to make target `depend', needed by `default'. Stop. make[3]: Leaving directory `.../src/mapi/glapi' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `.../src' make[1]: *** [default] Error 1 make[1]: Leaving directory `...' It's easily addressed by the first patch below, but the build later fails with make[5]: Entering directory `.../src/gallium/auxiliary/pipe-loader' make[5]: *** No rule to make target `default'. Stop. make[5]: Leaving directory `.../src/gallium/auxiliary/pipe-loader' All I really need is GL and GLU so after applying the patch I can build using the command $ bin/extract_git_sha1 ln -s linux-x86-64 configs/current (cd src/glsl make default) (cd src/mapi/glapi/gen make all) (cd src/mapi/glapi make default) (cd src/mesa make default) (cd src/glu/sgi make default) true However, later commit 7d7fe1b0 (automake: Rename variables in sources.mak to be automake compatible, 2012-05-16) renamed many Makefile variables but did not update configs/* accordingly. The result drops config-specific sources from pure-make builds. For example on x86_64 when linking to Mesa GL I get: undefined reference to `_mesa_x86_64_transform_points4_3d' undefined reference to `_mesa_3dnow_transform_points4_perspective' undefined reference to `_mesa_x86_64_transform_points4_identity' undefined reference to `_mesa_x86_64_transform_points4_general' undefined reference to `_mesa_3dnow_transform_points4_2d' undefined reference to `_mesa_x86_64_cpuid' undefined reference to `_mesa_3dnow_transform_points4_2d_no_rot' undefined reference to `_mesa_3dnow_transform_points4_3d_no_rot' The second patch below fixes this particular issue but there are probably many more cases. FYI, the reason I use the pure-make build with the above command sequence is to achieve a minimal build of just GL and GLU. I use it to run a nightly build of Mesa so I can run the VTK test suite against it to catch any Mesa regressions VTK exposes. Occasionally Mesa fails to build in sources unrelated to GL and GLU which then prevents that version from being tested, so I want to build only the minimal part needed. Thanks, -Brad diff --git a/configs/default b/configs/default index 40fa5e3..ca9ac71 100644 --- a/configs/default +++ b/configs/default @@ -99,7 +99,7 @@ MOTIF_CFLAGS = -I/usr/include/Motif1.2 # Directories to build LIB_DIR = lib -SRC_DIRS = glsl mapi/glapi mapi/vgapi mesa \ +SRC_DIRS = glsl mapi/glapi/gen mapi/glapi mapi/vgapi mesa \ gallium egl gallium/winsys gallium/targets glu GLU_DIRS = sgi DRIVER_DIRS = x11 osmesa diff --git a/configs/linux-x86-64 b/configs/linux-x86-64 index c2441e0..81bb36b 100644 --- a/configs/linux-x86-64 +++ b/configs/linux-x86-64 @@ -6,7 +6,7 @@ CONFIG_NAME = linux-x86-64 ARCH_FLAGS = -m64 -MESA_ASM_SOURCES = $(X86-64_SOURCES) +MESA_ASM_FILES = $(X86_64_FILES) GLAPI_ASM_SOURCES = $(X86-64_API) ASM_FLAGS = -DUSE_X86_64_ASM ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Restore depth texture state on glPopAttrib(GL_TEXTURE_BIT).
On 06/01/2012 04:52 AM, Kenneth Graunke wrote:
According to Table 6.17 in the GL 2.1 specification, DEPTH_TEXTURE_MODE,
TEXTURE_COMPARE_MODE, and TEXTURE_COMPARE_FUNC need to be restored on
glPopAttrib(GL_TEXTURE_BIT).
Makes a number of oglconform tests happier.
v2: Make restoration conditional on the ARB_shadow and ARB_depth_texture
extensions, as suggested by Brian. I'm not sure that any
implementations still remain that don't support those, but why not?
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunkekenn...@whitecape.org
---
src/mesa/main/attrib.c |8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index b114ec9..318d576 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -799,6 +799,14 @@ pop_texture_group(struct gl_context *ctx, struct
texture_state *texstate)
_mesa_TexParameterf(target, GL_TEXTURE_COMPARE_FAIL_VALUE_ARB,
samp-CompareFailValue);
}
+ if (ctx-Extensions.ARB_shadow) {
+_mesa_TexParameteri(target, GL_TEXTURE_COMPARE_MODE,
+samp-CompareMode);
+_mesa_TexParameteri(target, GL_TEXTURE_COMPARE_FUNC,
+samp-CompareFunc);
+ }
+ if (ctx-Extensions.ARB_depth_texture)
+_mesa_TexParameteri(target, GL_DEPTH_TEXTURE_MODE,
samp-DepthMode);
}
/* remove saved references to the texture objects */
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] Is the pure-make build system still supported?
On 06/01/2012 07:32 AM, Brad King wrote: Hi Folks, Since commit 0ce0f7c0 (mesa: Remove the generated glapi from source control, and just build it, 2012-05-15) I get this: $ make linux-x86-64 ... make[3]: Entering directory `.../src/mapi/glapi' make[3]: *** No rule to make target `depend', needed by `default'. Stop. make[3]: Leaving directory `.../src/mapi/glapi' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `.../src' make[1]: *** [default] Error 1 make[1]: Leaving directory `...' It's easily addressed by the first patch below, but the build later fails with make[5]: Entering directory `.../src/gallium/auxiliary/pipe-loader' make[5]: *** No rule to make target `default'. Stop. make[5]: Leaving directory `.../src/gallium/auxiliary/pipe-loader' All I really need is GL and GLU so after applying the patch I can build using the command $ bin/extract_git_sha1 ln -s linux-x86-64 configs/current (cd src/glsl make default) (cd src/mapi/glapi/gen make all) (cd src/mapi/glapi make default) (cd src/mesa make default) (cd src/glu/sgi make default) true However, later commit 7d7fe1b0 (automake: Rename variables in sources.mak to be automake compatible, 2012-05-16) renamed many Makefile variables but did not update configs/* accordingly. The result drops config-specific sources from pure-make builds. For example on x86_64 when linking to Mesa GL I get: undefined reference to `_mesa_x86_64_transform_points4_3d' undefined reference to `_mesa_3dnow_transform_points4_perspective' undefined reference to `_mesa_x86_64_transform_points4_identity' undefined reference to `_mesa_x86_64_transform_points4_general' undefined reference to `_mesa_3dnow_transform_points4_2d' undefined reference to `_mesa_x86_64_cpuid' undefined reference to `_mesa_3dnow_transform_points4_2d_no_rot' undefined reference to `_mesa_3dnow_transform_points4_3d_no_rot' The second patch below fixes this particular issue but there are probably many more cases. FYI, the reason I use the pure-make build with the above command sequence is to achieve a minimal build of just GL and GLU. I use it to run a nightly build of Mesa so I can run the VTK test suite against it to catch any Mesa regressions VTK exposes. Occasionally Mesa fails to build in sources unrelated to GL and GLU which then prevents that version from being tested, so I want to build only the minimal part needed. The old makefile system is going away. You should transition to using autoconf or scons. For autoconf, I'm guessing you'll probably want to use something like this: ./autogen.sh --disable-dri --enable-xlib-glx --enable-osmesa -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel(R) Open Source Technology Center.
On Thu, May 31, 2012 at 8:19 PM, Kenneth Graunke kenn...@whitecape.orgwrote: Tungsten Graphics has not existed for several years, and the majority of ongoing development and support is done by Intel. I chose to include Open Source Technology Center to distinguish it from, say, the closed source Windows OpenGL driver. The one downside to this patch is that applications that pattern match against Intel may start applying workarounds meant for the Windows driver. However, it does seem like the right thing to do. This does change oglconform behavior. Acked-by: Eric Anholt e...@anholt.net Acked-by: Ian Romanick ian.d.roman...@intel.com Cc: Eugeni Dodonov eug...@dodonov.net Signed-off-by: Kenneth Graunke kenn...@whitecape.org Acked-by: Eugeni Dodonov eugeni.dodo...@intel.com Just to confirm my thoughts - this change would go in the 8.1 release as the earliest, correct? -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50593] New: Account request
https://bugs.freedesktop.org/show_bug.cgi?id=50593 Bug #: 50593 Summary: Account request Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: v...@ovi.com I request an account ; Vincent Lejeune v...@ovi.com Account name : vlj -- 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 50593] Account request
https://bugs.freedesktop.org/show_bug.cgi?id=50593 --- Comment #1 from vincent v...@ovi.com 2012-06-01 08:30:43 PDT --- Created attachment 62382 -- https://bugs.freedesktop.org/attachment.cgi?id=62382 ssh public 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 50593] Account request
https://bugs.freedesktop.org/show_bug.cgi?id=50593 --- Comment #2 from vincent v...@ovi.com 2012-06-01 08:31:11 PDT --- Created attachment 62383 -- https://bugs.freedesktop.org/attachment.cgi?id=62383 gpg public 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
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On 6/1/12 3:33 AM, Oliver McFadden wrote: Furthermore it actually doesn't render correctly with my encodings (en_GB and en_US: UTF-8 and ISO-8859-1, and various Finnish and Swedish ones left out for brevity. Okay, problem on my end, but I'm probably not the only one (or maybe I am just an idiot who can't setup encodings correctly.) Wouldn't Intel(R) Open Source ... be sufficient? Wouldn't Intel Open Source ... be sufficient? - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50475] src/glx/glxclient.h:54:30: fatal error: glapi/glapitable.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=50475 Brian Paul brian.e.p...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Brian Paul brian.e.p...@gmail.com 2012-06-01 09:13:42 PDT --- This should be fixed with commit 091a61a8d5468365ec2ade2535dc8c439095cf18 -- 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] intel: Change vendor string to Intel(R) Open Source Technology Center.
On 06/01/2012 07:10 AM, Eugeni Dodonov wrote: On Thu, May 31, 2012 at 8:19 PM, Kenneth Graunke kenn...@whitecape.org mailto:kenn...@whitecape.org wrote: Tungsten Graphics has not existed for several years, and the majority of ongoing development and support is done by Intel. I chose to include Open Source Technology Center to distinguish it from, say, the closed source Windows OpenGL driver. The one downside to this patch is that applications that pattern match against Intel may start applying workarounds meant for the Windows driver. However, it does seem like the right thing to do. This does change oglconform behavior. Acked-by: Eric Anholt e...@anholt.net mailto:e...@anholt.net Acked-by: Ian Romanick ian.d.roman...@intel.com mailto:ian.d.roman...@intel.com Cc: Eugeni Dodonov eug...@dodonov.net mailto:eug...@dodonov.net Signed-off-by: Kenneth Graunke kenn...@whitecape.org mailto:kenn...@whitecape.org Acked-by: Eugeni Dodonov eugeni.dodo...@intel.com mailto:eugeni.dodo...@intel.com Just to confirm my thoughts - this change would go in the 8.1 release as the earliest, correct? Yes, of course. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On Fri, Jun 01, 2012 at 11:23:17AM -0400, Adam Jackson wrote: On 6/1/12 3:33 AM, Oliver McFadden wrote: Furthermore it actually doesn't render correctly with my encodings (en_GB and en_US: UTF-8 and ISO-8859-1, and various Finnish and Swedish ones left out for brevity. Okay, problem on my end, but I'm probably not the only one (or maybe I am just an idiot who can't setup encodings correctly.) Wouldn't Intel(R) Open Source ... be sufficient? Wouldn't Intel Open Source ... be sufficient? I am not a lawyer, period. Certainly not an Intel lawyer, therefore no comment. That being said, from a technical standpoint, using (R) as standard ASCII instead of the UTF-8 character might be a good compromise considering we cannot guarantee correct display of the UTF-8 character everywhere. -- Oliver McFadden. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Fail if egl x11 platform dependencies are not available
Currently, if you pass --with-egl-platforms=x11 but xcb-dri2 isn't available we just silently fail and disables building the EGL DRI2 driver. This commit cleans up the EGL platfrom checking and fails if a selected platform can't find its required dependencies. --- configure.ac | 71 +- 1 file changed, 40 insertions(+), 31 deletions(-) diff --git a/configure.ac b/configure.ac index 527accc..32f80c8 100644 --- a/configure.ac +++ b/configure.ac @@ -1433,20 +1433,6 @@ if test x$enable_egl = xyes; then if test $have_libudev = yes; then DEFINES=$DEFINES -DHAVE_LIBUDEV fi -if test x$enable_dri = xyes; then -# build egl_dri2 when xcb-dri2 is available -PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], - [have_xcb_dri2=yes],[have_xcb_dri2=no]) -if test $have_xcb_dri2 = yes; then - HAVE_EGL_DRIVER_DRI2=1 -# workaround a bug in xcb-dri2 generated by xcb-proto 1.6 - save_LIBS=$LIBS -AC_CHECK_LIB(xcb-dri2, xcb_dri2_connect_alignment_pad, [], - [DEFINES=$DEFINES -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN]) - LIBS=$save_LIBS -fi - fi - fi fi AC_SUBST([EGL_LIB_DEPS]) @@ -1722,6 +1708,9 @@ esac AC_SUBST([VG_LIB_DEPS]) AC_SUBST([EGL_CLIENT_APIS]) +dnl +dnl EGL Platforms configuration +dnl AC_ARG_WITH([egl-platforms], [AS_HELP_STRING([--with-egl-platforms@:@=DIRS...@:@], [comma delimited native platforms libEGL supports, e.g. @@ -1739,28 +1728,48 @@ if test x$with_egl_platforms != x -a x$enable_egl != xyes; then AC_MSG_ERROR([cannot build egl state tracker without EGL library]) fi -# verify the requested driver directories exist +# Do per-EGL platform setups and checks egl_platforms=`IFS=', '; echo $with_egl_platforms` for plat in $egl_platforms; do -test -d $srcdir/src/gallium/state_trackers/egl/$plat || \ -AC_MSG_ERROR([EGL platform '$plat' does not exist]) -if test $plat = fbdev; then -GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/fbdev -fi -if test $plat = null; then -GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/null -fi - if test $plat = wayland; then + case $plat in + fbdev|null) + GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/$plat + ;; + + wayland) + HAVE_EGL_DRIVER_DRI2=1 PKG_CHECK_MODULES([WAYLAND], [wayland-client wayland-server],, \ [AC_MSG_ERROR([cannot find libwayland-client])]) -GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/wayland + GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/wayland + + m4_ifdef([WAYLAND_SCANNER_RULES], + [WAYLAND_SCANNER_RULES(['$(top_srcdir)/src/egl/wayland/wayland-drm/protocol'])]) + ;; + + x11) + HAVE_EGL_DRIVER_DRI2=1 + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes]) + # workaround a bug in xcb-dri2 generated by xcb-proto 1.6 + save_LIBS=$LIBS + AC_CHECK_LIB(xcb-dri2, xcb_dri2_connect_alignment_pad, [], +[DEFINES=$DEFINES -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN]) + LIBS=$save_LIBS + ;; + + drm) + HAVE_EGL_DRIVER_DRI2=1 + test x$enable_gbm = xno + AC_MSG_ERROR([EGL platform drm needs gbm]) + ;; + + android|gdi) + ;; + + *) + AC_MSG_ERROR([EGL platform '$plat' does not exist]) + ;; + esac -m4_ifdef([WAYLAND_SCANNER_RULES], - [WAYLAND_SCANNER_RULES(['$(top_srcdir)/src/egl/wayland/wayland-drm/protocol'])]) - fi -if test $plat = drm test x$enable_gbm = xno; then -AC_MSG_ERROR([EGL platform drm needs gbm]) -fi case $plat$have_libudev in waylandno|drmno) AC_MSG_ERROR([cannot build $plat platfrom without udev]) ;; -- 1.7.10.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On 6/1/12 2:06 PM, Oliver McFadden wrote: On Fri, Jun 01, 2012 at 11:23:17AM -0400, Adam Jackson wrote: On 6/1/12 3:33 AM, Oliver McFadden wrote: Wouldn't Intel(R) Open Source ... be sufficient? Wouldn't Intel Open Source ... be sufficient? I am not a lawyer, period. Certainly not an Intel lawyer, therefore no comment. That being said, from a technical standpoint, using (R) as standard ASCII instead of the UTF-8 character might be a good compromise considering we cannot guarantee correct display of the UTF-8 character everywhere. If it's a thing that needs compromise, sure, I suppose. But I'd be fascinated to know why your lawyers think they need a marca registrada in a place that (afaik) no other vendor thinks they do. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is the pure-make build system still supported?
On 06/01/2012 10:06 AM, Brian Paul wrote: On 06/01/2012 07:32 AM, Brad King wrote: undefined reference to `_mesa_x86_64_transform_points4_3d' undefined reference to `_mesa_3dnow_transform_points4_perspective' undefined reference to `_mesa_x86_64_transform_points4_identity' undefined reference to `_mesa_x86_64_transform_points4_general' undefined reference to `_mesa_3dnow_transform_points4_2d' undefined reference to `_mesa_x86_64_cpuid' undefined reference to `_mesa_3dnow_transform_points4_2d_no_rot' undefined reference to `_mesa_3dnow_transform_points4_3d_no_rot' The old makefile system is going away. Okay, thanks for confirming. I'll switch to autotools. ./autogen.sh --disable-dri --enable-xlib-glx --enable-osmesa Thanks, that got me started. I ended up using ./autogen.sh --disable-dri --disable-egl --enable-xlib-glx \ --enable-osmesa --without-gallium-drivers However, I still get the above undefined symbols on x86_64 when linking to the resulting GL library. The patch below (also in my previous post) solves it. It seems configs/* is still in use even by the autotools system. -Brad diff --git a/configs/linux-x86-64 b/configs/linux-x86-64 index c2441e0..81bb36b 100644 --- a/configs/linux-x86-64 +++ b/configs/linux-x86-64 @@ -6,7 +6,7 @@ CONFIG_NAME = linux-x86-64 ARCH_FLAGS = -m64 -MESA_ASM_SOURCES = $(X86-64_SOURCES) +MESA_ASM_FILES = $(X86_64_FILES) GLAPI_ASM_SOURCES = $(X86-64_API) ASM_FLAGS = -DUSE_X86_64_ASM ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
Teach 'configure' to read the default GL_LIB, GLU_LIB, and OSMESA_LIB
values from the environment. This allows one to mangle the library
names (without also mangling the symbol names) to make them distinct
from other GL libraries on the system.
---
On 06/01/2012 10:06 AM, Brian Paul wrote:
You should transition to using autoconf
One feature I used in the pure-make build system was to create a custom
configs/current to set GL_LIB, GLU_LIB, and OSMESA_LIB to have a Mesa
prefix. This helps ensure that VTK both builds and runs against my
nightly Mesa build regardless of what other GL libraries appear in
the dynamic loader's search path. With this patch I can run
$ GL_LIB=MesaGL GLU_LIB=MesaGLU OSMESA_LIB=MesaOSMesa ./autogen.sh ...
to build with custom library names. Please review.
Thanks,
-Brad
configure.ac | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9fb8149..7f6ba96 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,12 @@ else
LIB_EXTENSION='so' ;;
esac
fi
+AC_ARG_VAR([GL_LIB],[name of GL library @:@default=GL@:@])
+AC_ARG_VAR([GLU_LIB],[name of GLU library @:@default=GLU@:@])
+AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @:@default=OSMesa@:@])
+GL_LIB=${GL_LIB-GL}
+GLU_LIB=${GLU_LIB-GLU}
+OSMESA_LIB=${OSMESA_LIB-OSMesa}
dnl
dnl Mangled Mesa support
@@ -365,19 +371,16 @@ AC_ARG_ENABLE([mangling],
[enable_mangling=${enableval}],
[enable_mangling=no]
)
-GL_LIB=GL
-GLU_LIB=GLU
-OSMESA_LIB=OSMesa
if test x${enable_mangling} = xyes ; then
DEFINES=${DEFINES} -DUSE_MGL_NAMESPACE
- GL_LIB=MangledGL
- GLU_LIB=MangledGLU
- OSMESA_LIB=MangledOSMesa
+ GL_LIB=Mangled${GL_LIB}
+ GLU_LIB=Mangled${GLU_LIB}
+ OSMESA_LIB=Mangled${OSMESA_LIB}
fi
AC_SUBST([GL_LIB])
AC_SUBST([GLU_LIB])
AC_SUBST([OSMESA_LIB])
-AM_CONDITIONAL(HAVE_MANGLED_GL, test $GL_LIB = MangledGL)
+AM_CONDITIONAL(HAVE_MANGLED_GL, test x${enable_mangling} = xyes)
dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] Add vertex id to llvmpipe.
Hi, The following pair of patches add gl_VertexID support to llvmpipe. They also simplify the system value fetch methodology (hopefully generating better code in the end) and fixes some issues with gl_InstanceID. The I don't understand how it could ever work kind of issues, converting from int32 to float twice is not good, usually. Best, OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] llvmpipe: Simplify and fix system variables fetch.
The system array values concept doesn't really because it expects the
system values to be fixed per call, which is wrong for gl_VertexID and
iffy for gl_SampleID. So this patch does two things:
- kill the array, have emit_fetch_system_value directly pick the
values it needs (only gl_InstanceID for now, as the previous code)
- correctly handle the expected type in emit_fetch_system_value
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 11 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 88 +++
src/gallium/drivers/llvmpipe/lp_state_fs.c |2 +-
4 files changed, 33 insertions(+), 78 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 4058e11..d5eb727 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -456,7 +456,7 @@ generate_vs(struct draw_llvm *llvm,
LLVMBuilderRef builder,
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS],
-LLVMValueRef system_values_array,
+LLVMValueRef instance_id,
LLVMValueRef context_ptr,
struct lp_build_sampler_soa *draw_sampler,
boolean clamp_vertex_color)
@@ -488,7 +488,7 @@ generate_vs(struct draw_llvm *llvm,
vs_type,
NULL /*struct lp_build_mask_context *mask*/,
consts_ptr,
- system_values_array,
+ instance_id,
NULL /*pos*/,
inputs,
outputs,
@@ -1246,7 +1246,6 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
LLVMValueRef stride, step, io_itr;
LLVMValueRef io_ptr, vbuffers_ptr, vb_ptr;
LLVMValueRef instance_id;
- LLVMValueRef system_values_array;
LLVMValueRef zero = lp_build_const_int32(gallivm, 0);
LLVMValueRef one = lp_build_const_int32(gallivm, 1);
struct draw_context *draw = llvm-draw;
@@ -1337,9 +1336,6 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
lp_build_context_init(bld, gallivm, lp_type_int(32));
- system_values_array = lp_build_system_values_array(gallivm, vs_info,
- instance_id, NULL);
-
/* function will return non-zero i32 value if any clipped vertices */
ret_ptr = lp_build_alloca(gallivm, int32_type, );
LLVMBuildStore(builder, zero, ret_ptr);
@@ -1415,7 +1411,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
builder,
outputs,
ptr_aos,
- system_values_array,
+ instance_id,
context_ptr,
sampler,
variant-key.clamp_vertex_color);
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
index 141e799..c4e690c 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
@@ -205,7 +205,7 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm,
struct lp_type type,
struct lp_build_mask_context *mask,
LLVMValueRef consts_ptr,
- LLVMValueRef system_values_array,
+ LLVMValueRef instance_id,
const LLVMValueRef *pos,
const LLVMValueRef (*inputs)[4],
LLVMValueRef (*outputs)[4],
@@ -225,13 +225,6 @@ lp_build_tgsi_aos(struct gallivm_state *gallivm,
const struct tgsi_shader_info *info);
-LLVMValueRef
-lp_build_system_values_array(struct gallivm_state *gallivm,
- const struct tgsi_shader_info *info,
- LLVMValueRef instance_id,
- LLVMValueRef facing);
-
-
struct lp_exec_mask {
struct lp_build_context *bld;
@@ -388,7 +381,7 @@ struct lp_build_tgsi_soa_context
*/
LLVMValueRef inputs_array;
- LLVMValueRef system_values_array;
+ LLVMValueRef instance_id;
/** bitmask indicating which register files are accessed indirectly */
unsigned indirect_files;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 412dc0c..26be902 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -786,18 +786,37 @@ emit_fetch_system_value(
{
struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
struct gallivm_state *gallivm = bld-bld_base.base.gallivm;
+ const struct tgsi_shader_info *info = bld-bld_base.info;
LLVMBuilderRef builder = gallivm-builder;
- LLVMValueRef
[Mesa-dev] [PATCH 2/2] llvmpipe: Add vertex id support.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 --
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |3 ++-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |7 +++
src/gallium/drivers/llvmpipe/lp_state_fs.c |2 +-
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index d5eb727..71125ba 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -457,6 +457,7 @@ generate_vs(struct draw_llvm *llvm,
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS],
LLVMValueRef instance_id,
+LLVMValueRef vertex_id,
LLVMValueRef context_ptr,
struct lp_build_sampler_soa *draw_sampler,
boolean clamp_vertex_color)
@@ -489,6 +490,7 @@ generate_vs(struct draw_llvm *llvm,
NULL /*struct lp_build_mask_context *mask*/,
consts_ptr,
instance_id,
+ vertex_id,
NULL /*pos*/,
inputs,
outputs,
@@ -1245,7 +1247,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
LLVMValueRef count, fetch_elts, fetch_count;
LLVMValueRef stride, step, io_itr;
LLVMValueRef io_ptr, vbuffers_ptr, vb_ptr;
- LLVMValueRef instance_id;
+ LLVMValueRef instance_id, vertex_id;
LLVMValueRef zero = lp_build_const_int32(gallivm, 0);
LLVMValueRef one = lp_build_const_int32(gallivm, 1);
struct draw_context *draw = llvm-draw;
@@ -1375,6 +1377,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
lp_build_printf(builder, --- io %d = %p, loop counter %d\n,
io_itr, io, lp_loop.counter);
#endif
+ vertex_id = lp_build_zero(gallivm, lp_type_uint_vec(32));
for (i = 0; i TGSI_NUM_CHANNELS; ++i) {
LLVMValueRef true_index =
LLVMBuildAdd(builder,
@@ -1392,7 +1395,9 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
true_index, 1, );
true_index = LLVMBuildLoad(builder, fetch_ptr, fetch_elt);
}
-
+
+ vertex_id = LLVMBuildInsertElement(gallivm-builder, vertex_id,
true_index,
+lp_build_const_int32(gallivm, i),
);
for (j = 0; j draw-pt.nr_vertex_elements; ++j) {
struct pipe_vertex_element *velem = draw-pt.vertex_element[j];
LLVMValueRef vb_index =
@@ -1412,6 +1417,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
outputs,
ptr_aos,
instance_id,
+ vertex_id,
context_ptr,
sampler,
variant-key.clamp_vertex_color);
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
index c4e690c..f87f899 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
@@ -206,6 +206,7 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm,
struct lp_build_mask_context *mask,
LLVMValueRef consts_ptr,
LLVMValueRef instance_id,
+ LLVMValueRef vertex_id,
const LLVMValueRef *pos,
const LLVMValueRef (*inputs)[4],
LLVMValueRef (*outputs)[4],
@@ -381,7 +382,7 @@ struct lp_build_tgsi_soa_context
*/
LLVMValueRef inputs_array;
- LLVMValueRef instance_id;
+ LLVMValueRef instance_id, vertex_id;
/** bitmask indicating which register files are accessed indirectly */
unsigned indirect_files;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 26be902..e1abae8 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -799,6 +799,11 @@ emit_fetch_system_value(
atype = TGSI_TYPE_UNSIGNED;
break;
+ case TGSI_SEMANTIC_VERTEXID:
+ res = bld-vertex_id;
+ atype = TGSI_TYPE_FLOAT;
+ break;
+
default:
assert(!unexpected semantic in emit_fetch_system_value);
res = bld_base-base.zero;
@@ -1996,6 +2001,7 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm,
struct lp_build_mask_context *mask,
LLVMValueRef consts_ptr,
LLVMValueRef instance_id,
+ LLVMValueRef vertex_id,
const LLVMValueRef *pos,
const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS],
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
@@
Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel® Open Source Technology Center.
On 06/01/2012 08:23 AM, Adam Jackson wrote: On 6/1/12 3:33 AM, Oliver McFadden wrote: Furthermore it actually doesn't render correctly with my encodings (en_GB and en_US: UTF-8 and ISO-8859-1, and various Finnish and Swedish ones left out for brevity. Okay, problem on my end, but I'm probably not the only one (or maybe I am just an idiot who can't setup encodings correctly.) Wouldn't Intel(R) Open Source ... be sufficient? Wouldn't Intel Open Source ... be sufficient? - ajax That sounds reasonable to me. Pushed (as Intel Open Source Technology Center). Bike-shedding concluded. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] Add vertex id to llvmpipe. (v2)
Hi, The following pair of patches add gl_VertexID support to llvmpipe. They also simplify the system value fetch methodology (hopefully generating better code in the end) and fixes some issues with gl_InstanceID. The I don't understand how it could ever work kind of issues, converting from int32 to float twice is not good, usually. v2: Fix a stupid type error for vertex id. Best, OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] llvmpipe: Simplify and fix system variables fetch.
The system array values concept doesn't really because it expects the
system values to be fixed per call, which is wrong for gl_VertexID and
iffy for gl_SampleID. So this patch does two things:
- kill the array, have emit_fetch_system_value directly pick the
values it needs (only gl_InstanceID for now, as the previous code)
- correctly handle the expected type in emit_fetch_system_value
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 11 +--
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 88 +++
src/gallium/drivers/llvmpipe/lp_state_fs.c |2 +-
4 files changed, 33 insertions(+), 78 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 4058e11..d5eb727 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -456,7 +456,7 @@ generate_vs(struct draw_llvm *llvm,
LLVMBuilderRef builder,
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS],
-LLVMValueRef system_values_array,
+LLVMValueRef instance_id,
LLVMValueRef context_ptr,
struct lp_build_sampler_soa *draw_sampler,
boolean clamp_vertex_color)
@@ -488,7 +488,7 @@ generate_vs(struct draw_llvm *llvm,
vs_type,
NULL /*struct lp_build_mask_context *mask*/,
consts_ptr,
- system_values_array,
+ instance_id,
NULL /*pos*/,
inputs,
outputs,
@@ -1246,7 +1246,6 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
LLVMValueRef stride, step, io_itr;
LLVMValueRef io_ptr, vbuffers_ptr, vb_ptr;
LLVMValueRef instance_id;
- LLVMValueRef system_values_array;
LLVMValueRef zero = lp_build_const_int32(gallivm, 0);
LLVMValueRef one = lp_build_const_int32(gallivm, 1);
struct draw_context *draw = llvm-draw;
@@ -1337,9 +1336,6 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
lp_build_context_init(bld, gallivm, lp_type_int(32));
- system_values_array = lp_build_system_values_array(gallivm, vs_info,
- instance_id, NULL);
-
/* function will return non-zero i32 value if any clipped vertices */
ret_ptr = lp_build_alloca(gallivm, int32_type, );
LLVMBuildStore(builder, zero, ret_ptr);
@@ -1415,7 +1411,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
builder,
outputs,
ptr_aos,
- system_values_array,
+ instance_id,
context_ptr,
sampler,
variant-key.clamp_vertex_color);
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
index 141e799..c4e690c 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
@@ -205,7 +205,7 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm,
struct lp_type type,
struct lp_build_mask_context *mask,
LLVMValueRef consts_ptr,
- LLVMValueRef system_values_array,
+ LLVMValueRef instance_id,
const LLVMValueRef *pos,
const LLVMValueRef (*inputs)[4],
LLVMValueRef (*outputs)[4],
@@ -225,13 +225,6 @@ lp_build_tgsi_aos(struct gallivm_state *gallivm,
const struct tgsi_shader_info *info);
-LLVMValueRef
-lp_build_system_values_array(struct gallivm_state *gallivm,
- const struct tgsi_shader_info *info,
- LLVMValueRef instance_id,
- LLVMValueRef facing);
-
-
struct lp_exec_mask {
struct lp_build_context *bld;
@@ -388,7 +381,7 @@ struct lp_build_tgsi_soa_context
*/
LLVMValueRef inputs_array;
- LLVMValueRef system_values_array;
+ LLVMValueRef instance_id;
/** bitmask indicating which register files are accessed indirectly */
unsigned indirect_files;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 412dc0c..26be902 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -786,18 +786,37 @@ emit_fetch_system_value(
{
struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
struct gallivm_state *gallivm = bld-bld_base.base.gallivm;
+ const struct tgsi_shader_info *info = bld-bld_base.info;
LLVMBuilderRef builder = gallivm-builder;
- LLVMValueRef
[Mesa-dev] [PATCH 2/2] llvmpipe: Add vertex id support.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 10 --
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |3 ++-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |7 +++
src/gallium/drivers/llvmpipe/lp_state_fs.c |2 +-
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index d5eb727..71125ba 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -457,6 +457,7 @@ generate_vs(struct draw_llvm *llvm,
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS],
LLVMValueRef instance_id,
+LLVMValueRef vertex_id,
LLVMValueRef context_ptr,
struct lp_build_sampler_soa *draw_sampler,
boolean clamp_vertex_color)
@@ -489,6 +490,7 @@ generate_vs(struct draw_llvm *llvm,
NULL /*struct lp_build_mask_context *mask*/,
consts_ptr,
instance_id,
+ vertex_id,
NULL /*pos*/,
inputs,
outputs,
@@ -1245,7 +1247,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
LLVMValueRef count, fetch_elts, fetch_count;
LLVMValueRef stride, step, io_itr;
LLVMValueRef io_ptr, vbuffers_ptr, vb_ptr;
- LLVMValueRef instance_id;
+ LLVMValueRef instance_id, vertex_id;
LLVMValueRef zero = lp_build_const_int32(gallivm, 0);
LLVMValueRef one = lp_build_const_int32(gallivm, 1);
struct draw_context *draw = llvm-draw;
@@ -1375,6 +1377,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
lp_build_printf(builder, --- io %d = %p, loop counter %d\n,
io_itr, io, lp_loop.counter);
#endif
+ vertex_id = lp_build_zero(gallivm, lp_type_uint_vec(32));
for (i = 0; i TGSI_NUM_CHANNELS; ++i) {
LLVMValueRef true_index =
LLVMBuildAdd(builder,
@@ -1392,7 +1395,9 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
true_index, 1, );
true_index = LLVMBuildLoad(builder, fetch_ptr, fetch_elt);
}
-
+
+ vertex_id = LLVMBuildInsertElement(gallivm-builder, vertex_id,
true_index,
+lp_build_const_int32(gallivm, i),
);
for (j = 0; j draw-pt.nr_vertex_elements; ++j) {
struct pipe_vertex_element *velem = draw-pt.vertex_element[j];
LLVMValueRef vb_index =
@@ -1412,6 +1417,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
outputs,
ptr_aos,
instance_id,
+ vertex_id,
context_ptr,
sampler,
variant-key.clamp_vertex_color);
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
index c4e690c..f87f899 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.h
@@ -206,6 +206,7 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm,
struct lp_build_mask_context *mask,
LLVMValueRef consts_ptr,
LLVMValueRef instance_id,
+ LLVMValueRef vertex_id,
const LLVMValueRef *pos,
const LLVMValueRef (*inputs)[4],
LLVMValueRef (*outputs)[4],
@@ -381,7 +382,7 @@ struct lp_build_tgsi_soa_context
*/
LLVMValueRef inputs_array;
- LLVMValueRef instance_id;
+ LLVMValueRef instance_id, vertex_id;
/** bitmask indicating which register files are accessed indirectly */
unsigned indirect_files;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 26be902..37599da 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -799,6 +799,11 @@ emit_fetch_system_value(
atype = TGSI_TYPE_UNSIGNED;
break;
+ case TGSI_SEMANTIC_VERTEXID:
+ res = bld-vertex_id;
+ atype = TGSI_TYPE_UNSIGNED;
+ break;
+
default:
assert(!unexpected semantic in emit_fetch_system_value);
res = bld_base-base.zero;
@@ -1996,6 +2001,7 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm,
struct lp_build_mask_context *mask,
LLVMValueRef consts_ptr,
LLVMValueRef instance_id,
+ LLVMValueRef vertex_id,
const LLVMValueRef *pos,
const LLVMValueRef (*inputs)[TGSI_NUM_CHANNELS],
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
@@
Re: [Mesa-dev] [PATCH 2/6] mesa intel driver:
On Thu, 31 May 2012 17:23:59 +0800, Zhao halley halley.z...@intel.com wrote: add YUYV format for dri image YUYV image doesn't use for texture --- src/mesa/drivers/dri/intel/intel_screen.c|5 + src/mesa/drivers/dri/intel/intel_tex_image.c |3 +++ 2 files changed, 8 insertions(+), 0 deletions(-) mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_screen.c mode change 100644 = 100755 src/mesa/drivers/dri/intel/intel_tex_image.c diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c old mode 100644 new mode 100755 index 458178f..5ff2e49 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen *screen, image-internal_format = GL_RGB; image-data_type = GL_UNSIGNED_BYTE; break; +case __DRI_IMAGE_FORMAT_YUYV: + image-format = MESA_FORMAT_YCBCR; // no detailed YUV format in mesa yet + image-internal_format = GL_LUMINANCE; // no detailed YUV format in gles2 yet + image-data_type = GL_UNSIGNED_BYTE; + break; default: free(image); return NULL; I don't like seeing these XXXs added that suggest that this commit isn't ready. diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c b/src/mesa/drivers/dri/intel/intel_tex_image.c old mode 100644 new mode 100755 index 094d3cd..e5c3bdc --- a/src/mesa/drivers/dri/intel/intel_tex_image.c +++ b/src/mesa/drivers/dri/intel/intel_tex_image.c @@ -388,6 +388,9 @@ intel_image_target_texture_2d(struct gl_context *ctx, GLenum target, if (image == NULL) return; + if (image-format == MESA_FORMAT_YCBCR) +return; + intel_set_texture_image_region(ctx, texImage, image-region, target, image-internal_format, image-format); } So, you don't actually attach the region to the texture? If you don't support rendering from the format as a texture, why is this not throwing an error? I don't understand yet how this series really gets used. As far as I understand, wayland likes to use the image directly as an overlay if possible, but sometimes it can't. At that point, it needs to be able to do GL rendering using that image as a source, right? So, how is the compositor supposed to handle the format in that case, if it can't texture from it? pgpAZTYsaU4Oe.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] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On Jun 1, 2012 12:13 PM, Brad King brad.k...@kitware.com wrote:
Teach 'configure' to read the default GL_LIB, GLU_LIB, and OSMESA_LIB
values from the environment. This allows one to mangle the library
names (without also mangling the symbol names) to make them distinct
from other GL libraries on the system.
---
On 06/01/2012 10:06 AM, Brian Paul wrote:
You should transition to using autoconf
One feature I used in the pure-make build system was to create a custom
configs/current to set GL_LIB, GLU_LIB, and OSMESA_LIB to have a Mesa
prefix. This helps ensure that VTK both builds and runs against my
nightly Mesa build regardless of what other GL libraries appear in
the dynamic loader's search path. With this patch I can run
$ GL_LIB=MesaGL GLU_LIB=MesaGLU OSMESA_LIB=MesaOSMesa ./autogen.sh ...
to build with custom library names. Please review.
Thanks,
-Brad
configure.ac | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9fb8149..7f6ba96 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,12 @@ else
LIB_EXTENSION='so' ;;
esac
fi
+AC_ARG_VAR([GL_LIB],[name of GL library @:@default=GL@:@])
+AC_ARG_VAR([GLU_LIB],[name of GLU library @:@default=GLU@:@])
+AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @:@default=OSMesa@:@])
+GL_LIB=${GL_LIB-GL}
+GLU_LIB=${GLU_LIB-GLU}
+OSMESA_LIB=${OSMESA_LIB-OSMesa}
I don't think this part is necessary. AC_ARG_VAR does this already. The
rest makes sense though.
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 50480] Commit f9d1562 breaks x86 build after x86_64 build
https://bugs.freedesktop.org/show_bug.cgi?id=50480 --- Comment #7 from Eric Anholt e...@anholt.net 2012-06-01 16:27:01 PDT --- commit 775ba11dcd8ddc46f78db3afe35de193a92515d0 Author: Eric Anholt e...@anholt.net Date: Wed May 30 13:31:27 2012 -0700 automake: Connect the libdricore target to make clean. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50480 Reviewed-by: Kenneth Graunke kenn...@whitecape.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Restore depth texture state on glPopAttrib(GL_TEXTURE_BIT).
On Fri, 1 Jun 2012 03:52:19 -0700, Kenneth Graunke kenn...@whitecape.org wrote: According to Table 6.17 in the GL 2.1 specification, DEPTH_TEXTURE_MODE, TEXTURE_COMPARE_MODE, and TEXTURE_COMPARE_FUNC need to be restored on glPopAttrib(GL_TEXTURE_BIT). Makes a number of oglconform tests happier. v2: Make restoration conditional on the ARB_shadow and ARB_depth_texture extensions, as suggested by Brian. I'm not sure that any implementations still remain that don't support those, but why not? i830 :( Reviewed-by: Eric Anholt e...@anholt.net pgpzpag4qsYCV.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Implement texture buffer objects on Gen6.
On Fri, 1 Jun 2012 04:30:18 -0700, Kenneth Graunke kenn...@whitecape.org wrote: Commit a07cf3397e332388d3599c83e50ac45511972890 added support for TBOs on Gen7, but missed Gen6. Passes piglit -t texture_buffer and oglconform's buffermapping basic.read.texture tests. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Reviewed-by: Eric Anholt e...@anholt.net pgpgiy7ZvZYWo.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] configure.ac: Fail if egl x11 platform dependencies are not available
On Fri, 1 Jun 2012 14:29:44 -0400, Kristian Høgsberg k...@bitplanet.net wrote: Currently, if you pass --with-egl-platforms=x11 but xcb-dri2 isn't available we just silently fail and disables building the EGL DRI2 driver. This commit cleans up the EGL platfrom checking and fails if a selected platform can't find its required dependencies. + wayland) + HAVE_EGL_DRIVER_DRI2=1 PKG_CHECK_MODULES([WAYLAND], [wayland-client wayland-server],, \ [AC_MSG_ERROR([cannot find libwayland-client])]) -GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/wayland + GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS sw/wayland + + m4_ifdef([WAYLAND_SCANNER_RULES], + [WAYLAND_SCANNER_RULES(['$(top_srcdir)/src/egl/wayland/wayland-drm/protocol'])]) + ;; + I note that this also turns on HAVE_EGL_DRIVER_DRI2 for a few platforms. That appears to be correct, but I wasn't expecting it from the commit mesage. pgp2KX5fE9JkU.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 49088] MapsGL labels doen't render properly on nouveau, r600, i965
https://bugs.freedesktop.org/show_bug.cgi?id=49088 Eric Appleman erapple...@gmail.com changed: What|Removed |Added CC||erapple...@gmail.com --- Comment #14 from Eric Appleman erapple...@gmail.com 2012-06-01 20:28:23 PDT --- Confirming on Sandy Bridge HD3000 (i965). -- 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
