Re: [Mesa-dev] [PATCH 9/9] vl/video_buffer: add YUYV and UYVY support
On 04.03.2012 14:59, Andy Furniss wrote: Christian König wrote: This gets xine working with VDPAU. Didn't for me but my xine may be borked :-( But then YUY2 with mplayer is also failing - vl/vl_video_buffer.c:451:vl_video_buffer_create_ex: Assertion `tmpl-chroma_format == PIPE_VIDEO_CHROMA_FORMAT_444' failed. Same stream works with xv and mplayer output looks the same, so I don't think it's an mplayer thing. That assertion is indeed incorrect now, but the problem lies even deeper. Neither our MPEG2 decoder nor xines software decoder can handle 4:2:2 streams, so I couldn't find a way to test that probably. Xine is just checking for YUY2 support before using VDPAU in any way, so with that patch you can at least play 4:2:0 streams. Thx for the tip with mplayer, it looks like mplayers software decoder+VDPAU can actually play those streams, so I now was able to hammer out some of the bugs. But sampling from those packet formats is still a bit buggy, need to work on that a bit more before I can commit those patches. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: don't enable tiling for STAGING and STREAM usage cases
This is a follow-up to my series.
Cc: Christian König deathsim...@vodafone.de
---
src/gallium/drivers/r600/r600_texture.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 6222410..e55e0d2 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -623,12 +623,13 @@ struct pipe_resource *r600_texture_create(struct
pipe_screen *screen,
unsigned array_mode = 0;
int r;
- if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER)
- !(templ-bind PIPE_BIND_SCANOUT)) {
- if (rscreen-use_surface_alloc) {
- if (permit_hardware_blit(screen, templ)) {
- array_mode = V_038000_ARRAY_2D_TILED_THIN1;
- }
+ if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER)) {
+ if (rscreen-use_surface_alloc
+ !(templ-bind PIPE_BIND_SCANOUT)
+ templ-usage != PIPE_USAGE_STAGING
+ templ-usage != PIPE_USAGE_STREAM
+ permit_hardware_blit(screen, templ)) {
+ array_mode = V_038000_ARRAY_2D_TILED_THIN1;
} else if (util_format_is_compressed(templ-format)) {
array_mode = V_038000_ARRAY_1D_TILED_THIN1;
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: don't enable tiling for STAGING and STREAM usage cases
On 05.03.2012 14:35, Marek Olšák wrote:
This is a follow-up to my series.
Cc: Christian Königdeathsim...@vodafone.de
---
src/gallium/drivers/r600/r600_texture.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 6222410..e55e0d2 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -623,12 +623,13 @@ struct pipe_resource *r600_texture_create(struct
pipe_screen *screen,
unsigned array_mode = 0;
int r;
- if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER)
- !(templ-bind PIPE_BIND_SCANOUT)) {
- if (rscreen-use_surface_alloc) {
- if (permit_hardware_blit(screen, templ)) {
- array_mode = V_038000_ARRAY_2D_TILED_THIN1;
- }
+ if (!(templ-flags R600_RESOURCE_FLAG_TRANSFER)) {
+ if (rscreen-use_surface_alloc
+ !(templ-bind PIPE_BIND_SCANOUT)
+ templ-usage != PIPE_USAGE_STAGING
+ templ-usage != PIPE_USAGE_STREAM
+ permit_hardware_blit(screen, templ)) {
+ array_mode = V_038000_ARRAY_2D_TILED_THIN1;
} else if (util_format_is_compressed(templ-format)) {
array_mode = V_038000_ARRAY_1D_TILED_THIN1;
}
Looks good to me:
Reviewed by: Christian König christian.koe...@amd.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 9/9] vl/video_buffer: add YUYV and UYVY support
Christian König wrote: That assertion is indeed incorrect now, but the problem lies even deeper. Neither our MPEG2 decoder nor xines software decoder can handle 4:2:2 streams, so I couldn't find a way to test that probably. Xine is just checking for YUY2 support before using VDPAU in any way, so with that patch you can at least play 4:2:0 streams. I had a grep around in the xinelib 1.21 sources and it doesn't look like it asks for VDP_YCBCR_FORMAT_YUYV (well not before the error I get so far). The query I think fails for me is - ./src/video_out/video_out_vdpau.c- st = vdp_video_surface_query_capabilities( vdp_device, VDP_CHROMA_TYPE_422, ok, max_surface_width, max_surface_height ); I also notice that vdpauinfo lists the new formats under 420 with no 422 line so I guess that's why it still fails for me. Thx for the tip with mplayer, it looks like mplayers software decoder+VDPAU can actually play those streams, so I now was able to hammer out some of the bugs. But sampling from those packet formats is still a bit buggy, need to work on that a bit more before I can commit those patches. FWIW the only mpeg2 422 I have gets output as planar, maybe that would be easier to implement but of course packed is also worth doing. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Use -no-undefined libtool flag in egl/main/Makefile.am
On 03/04/2012 08:17 AM, Jon TURNEY wrote: Use -no-undefined to assure libtool that the library has no unresolved symbols at link time, so that libtool will build a shared library on platforms require that all symbols are resolved when the library is linked. If I had a dollar for every time I wrote this patch, I'd have about $10 :-) Indeed. :( Acked-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Jon TURNEYjon.tur...@dronecode.org.uk --- src/egl/main/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am index ad1bbdb..a8072c1 100644 --- a/src/egl/main/Makefile.am +++ b/src/egl/main/Makefile.am @@ -74,7 +74,7 @@ libEGL_la_SOURCES = \ libEGL_la_LIBADD = \ $(EGL_LIB_DEPS) -libEGL_la_LDFLAGS = -version-number 1:0 +libEGL_la_LDFLAGS = -version-number 1:0 -no-undefined if HAVE_EGL_PLATFORM_X11 AM_CFLAGS += -DHAVE_X11_PLATFORM ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Link with -Wl,-r instead of -r.
This is required to link with clang: /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00400160. --- src/gallium/state_trackers/xa/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/state_trackers/xa/Makefile b/src/gallium/state_trackers/xa/Makefile index b42e619..9a822a0 100644 --- a/src/gallium/state_trackers/xa/Makefile +++ b/src/gallium/state_trackers/xa/Makefile @@ -39,7 +39,7 @@ default: $(XA_LIB_NAME) # Make the library $(XA_LIB_NAME): depend $(OBJECTS) - $(CC) -r -nostdlib -o $(XA_LIB_NAME) $(OBJECTS) + $(CC) -Wl,-r -nostdlib -o $(XA_LIB_NAME) $(OBJECTS) install: FORCE -- 1.7.7 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] tgsi: Fix conflict with fortify printf redirect in glibc.
Fixes clang error:
tgsi/tgsi_dump.c:72:12: error: no member named '__printf_chk' in 'struct
dump_ctx'
ctx-printf( ctx, %u, e );
~~~ ^
/usr/include/bits/stdio2.h:109:3: note: expanded from macro 'printf'
__printf_chk (__USE_FORTIFY_LEVEL - 1, __VA_ARGS__)
^
Idea stolen from:
http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg210998.html
---
src/gallium/auxiliary/tgsi/tgsi_dump.c | 34
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index 9963445..daed0e1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_dump.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c
@@ -48,7 +48,7 @@ struct dump_ctx
uint indentation;
- void (*printf)(struct dump_ctx *ctx, const char *format, ...);
+ void (*dump_printf)(struct dump_ctx *ctx, const char *format, ...);
};
static void
@@ -69,19 +69,19 @@ dump_enum(
uint enum_count )
{
if (e = enum_count)
- ctx-printf( ctx, %u, e );
+ ctx-dump_printf( ctx, %u, e );
else
- ctx-printf( ctx, %s, enums[e] );
+ ctx-dump_printf( ctx, %s, enums[e] );
}
-#define EOL() ctx-printf( ctx, \n )
-#define TXT(S) ctx-printf( ctx, %s, S )
-#define CHR(C) ctx-printf( ctx, %c, C )
-#define UIX(I) ctx-printf( ctx, 0x%x, I )
-#define UID(I) ctx-printf( ctx, %u, I )
-#define INSTID(I) ctx-printf( ctx, % 3u, I )
-#define SID(I) ctx-printf( ctx, %d, I )
-#define FLT(F) ctx-printf( ctx, %10.4f, F )
+#define EOL() ctx-dump_printf( ctx, \n )
+#define TXT(S) ctx-dump_printf( ctx, %s, S )
+#define CHR(C) ctx-dump_printf( ctx, %c, C )
+#define UIX(I) ctx-dump_printf( ctx, 0x%x, I )
+#define UID(I) ctx-dump_printf( ctx, %u, I )
+#define INSTID(I) ctx-dump_printf( ctx, % 3u, I )
+#define SID(I) ctx-dump_printf( ctx, %d, I )
+#define FLT(F) ctx-dump_printf( ctx, %10.4f, F )
#define ENM(E,ENUMS)dump_enum( ctx, E, ENUMS, sizeof( ENUMS ) / sizeof(
*ENUMS ) )
const char *
@@ -381,7 +381,7 @@ tgsi_dump_declaration(
{
struct dump_ctx ctx;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
iter_declaration( ctx.iter, (struct tgsi_full_declaration *)decl );
}
@@ -429,7 +429,7 @@ void tgsi_dump_property(
{
struct dump_ctx ctx;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
iter_property( ctx.iter, (struct tgsi_full_property *)prop );
}
@@ -458,7 +458,7 @@ tgsi_dump_immediate(
{
struct dump_ctx ctx;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
iter_immediate( ctx.iter, (struct tgsi_full_immediate *)imm );
}
@@ -613,7 +613,7 @@ tgsi_dump_instruction(
ctx.instno = instno;
ctx.indent = 0;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
ctx.indentation = 0;
iter_instruction( ctx.iter, (struct tgsi_full_instruction *)inst );
@@ -645,7 +645,7 @@ tgsi_dump(
ctx.instno = 0;
ctx.indent = 0;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
ctx.indentation = 0;
tgsi_iterate_shader( tokens, ctx.iter );
@@ -700,7 +700,7 @@ tgsi_dump_str(
ctx.base.instno = 0;
ctx.base.indent = 0;
- ctx.base.printf = str_dump_ctx_printf;
+ ctx.base.dump_printf = str_dump_ctx_printf;
ctx.base.indentation = 0;
ctx.str = str;
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] configure: Fix egl compilation without x11 headers
2012/3/1 Chad Versace chad.vers...@linux.intel.com: On 03/01/2012 11:39 AM, Benjamin Franzke wrote: 2012/3/1 Chad Versace chad.vers...@linux.intel.com: On 02/29/2012 07:36 AM, Benjamin Franzke wrote: We dont want eglplatform.h to typedef egl native types to x11 types, when x11 headers are not available. --- configure.ac | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 0caa1b1..92a0e52 100644 --- a/configure.ac +++ b/configure.ac @@ -1402,6 +1402,10 @@ if test x$enable_egl = xyes; then AC_CHECK_FUNC(mincore, [DEFINES=$DEFINES -DHAVE_MINCORE]) + if test $have_x != yes; then + DEFINES=$DEFINES -DMESA_EGL_NO_X11_HEADERS + fi + if test $enable_static != yes; then # build egl_glx when libGL is built if test x$enable_glx = xyes; then After examining the where the macro is used, in eglplatform.h ... --- snip --- #elif defined(__unix__) #ifdef MESA_EGL_NO_X11_HEADERS typedef void *EGLNativeDisplayType; typedef khronos_uint32_t EGLNativePixmapType; typedef khronos_uint32_t EGLNativeWindowType; #else /* X11 (tentative) */ #include X11/Xlib.h #include X11/Xutil.h typedef Display *EGLNativeDisplayType; typedef Pixmap EGLNativePixmapType; typedef Window EGLNativeWindowType; #endif /* MESA_EGL_NO_X11_HEADERS */ --- end snip --- I can't think of a valid reason for the #else branch to ever be taken. If you're building EGL on Unix/Linux, but not for gbm (__GBM__), Android (ANDRDOID), Wayland (WL_EGL_PLATFORM), or X (the default), then for what platform are you building libEGL? (The question is not rhetorical). The platform headers for wayland/gbm are not included when compiling src/egl/main/* or some other common code in st/egl, that is when the else branch is taken. So currently we include Xlib.h when building without x11 platform, that fails if its not available. Will add a note to the commit message. It appears that the patch may introduce a bug in the 64-bit build of libEGL, but I'm not certain. Here's my reasoning. 1. Suppose that - This patch is applied. - The system has no X headers installed. - Some Wayland application has a source file, broken.c, that #includes wayland-egl.h then EGL/egl.h. 2. In eglapi.c, which defines eglCreateWindowSurface, EGLNativeWindowType will be defined as khronos_uint32_t. 3. In broken.c, wayland-egl.h first defines WL_EGL_PLATFORM. Then EGLNativeWindowType will be defined as wl_egl_window*, a 64-bit type. Yes, thanks for pointing that out. We should just typedef them to khronos_uintptr_t instead. Without the patch, eglapi.c safely typedefs EGLNativeWindowType to XID, which matches the system's pointer size. - Chad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix valid texture target test in _mesa_GetTexLevelParameteriv()
On 03/02/2012 04:03 PM, Anuj Phogat wrote:
_mesa_max_texture_levels() is also used to test valid texture target
in _mesa_GetTexLevelParameteriv(). GL_TEXTURE_CUBE_MAP is not allowed
as texture target in glGetTexLevelParameter(). So, this should throw
GL_INVALID_ENUM error.
Few other functions which use _mesa_max_texture_levels() like
getcompressedteximage_error_check() and getteximage_error_check()
also don't accept GL_TEXTURE_CUBE_MAP.
Above fix makes piglit fbo-cubemap test to fail. This is because of
incorrect texture target passed to _mesa_max_texture_levels() in
framebuffer_texture(). Fixing that as well
Note: This is a candidate for the stable branches
Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
---
src/mesa/main/fbobject.c |2 +-
src/mesa/main/teximage.c |1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 6ee062d..281b1ca 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1994,7 +1994,7 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
}
if ((level 0) ||
- (level= _mesa_max_texture_levels(ctx, texObj-Target))) {
+ (level= _mesa_max_texture_levels(ctx, textarget))) {
_mesa_error(ctx, GL_INVALID_VALUE,
glFramebufferTexture%sEXT(level), caller);
return;
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4fb81e6..c0e5b9b 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -915,7 +915,6 @@ _mesa_max_texture_levels(struct gl_context *ctx, GLenum
target)
case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB:
case GL_TEXTURE_CUBE_MAP_POSITIVE_Z_ARB:
case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB:
- case GL_TEXTURE_CUBE_MAP_ARB:
case GL_PROXY_TEXTURE_CUBE_MAP_ARB:
return ctx-Extensions.ARB_texture_cube_map
? ctx-Const.MaxCubeTextureLevels : 0;
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] [PATCH] tgsi: Fix conflict with fortify printf redirect in glibc.
On 03/05/2012 11:37 AM, Johannes Obermayr wrote:
Fixes clang error:
tgsi/tgsi_dump.c:72:12: error: no member named '__printf_chk' in 'struct
dump_ctx'
ctx-printf( ctx, %u, e );
~~~ ^
/usr/include/bits/stdio2.h:109:3: note: expanded from macro 'printf'
__printf_chk (__USE_FORTIFY_LEVEL - 1, __VA_ARGS__)
^
Idea stolen from:
http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg210998.html
---
src/gallium/auxiliary/tgsi/tgsi_dump.c | 34
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index 9963445..daed0e1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_dump.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c
@@ -48,7 +48,7 @@ struct dump_ctx
uint indentation;
- void (*printf)(struct dump_ctx *ctx, const char *format, ...);
+ void (*dump_printf)(struct dump_ctx *ctx, const char *format, ...);
};
static void
@@ -69,19 +69,19 @@ dump_enum(
uint enum_count )
{
if (e= enum_count)
- ctx-printf( ctx, %u, e );
+ ctx-dump_printf( ctx, %u, e );
else
- ctx-printf( ctx, %s, enums[e] );
+ ctx-dump_printf( ctx, %s, enums[e] );
}
-#define EOL() ctx-printf( ctx, \n )
-#define TXT(S) ctx-printf( ctx, %s, S )
-#define CHR(C) ctx-printf( ctx, %c, C )
-#define UIX(I) ctx-printf( ctx, 0x%x, I )
-#define UID(I) ctx-printf( ctx, %u, I )
-#define INSTID(I) ctx-printf( ctx, % 3u, I )
-#define SID(I) ctx-printf( ctx, %d, I )
-#define FLT(F) ctx-printf( ctx, %10.4f, F )
+#define EOL() ctx-dump_printf( ctx, \n )
+#define TXT(S) ctx-dump_printf( ctx, %s, S )
+#define CHR(C) ctx-dump_printf( ctx, %c, C )
+#define UIX(I) ctx-dump_printf( ctx, 0x%x, I )
+#define UID(I) ctx-dump_printf( ctx, %u, I )
+#define INSTID(I) ctx-dump_printf( ctx, % 3u, I )
+#define SID(I) ctx-dump_printf( ctx, %d, I )
+#define FLT(F) ctx-dump_printf( ctx, %10.4f, F )
#define ENM(E,ENUMS)dump_enum( ctx, E, ENUMS, sizeof( ENUMS ) / sizeof(
*ENUMS ) )
const char *
@@ -381,7 +381,7 @@ tgsi_dump_declaration(
{
struct dump_ctx ctx;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
iter_declaration(ctx.iter, (struct tgsi_full_declaration *)decl );
}
@@ -429,7 +429,7 @@ void tgsi_dump_property(
{
struct dump_ctx ctx;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
iter_property(ctx.iter, (struct tgsi_full_property *)prop );
}
@@ -458,7 +458,7 @@ tgsi_dump_immediate(
{
struct dump_ctx ctx;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
iter_immediate(ctx.iter, (struct tgsi_full_immediate *)imm );
}
@@ -613,7 +613,7 @@ tgsi_dump_instruction(
ctx.instno = instno;
ctx.indent = 0;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
ctx.indentation = 0;
iter_instruction(ctx.iter, (struct tgsi_full_instruction *)inst );
@@ -645,7 +645,7 @@ tgsi_dump(
ctx.instno = 0;
ctx.indent = 0;
- ctx.printf = dump_ctx_printf;
+ ctx.dump_printf = dump_ctx_printf;
ctx.indentation = 0;
tgsi_iterate_shader( tokens,ctx.iter );
@@ -700,7 +700,7 @@ tgsi_dump_str(
ctx.base.instno = 0;
ctx.base.indent = 0;
- ctx.base.printf =str_dump_ctx_printf;
+ ctx.base.dump_printf =str_dump_ctx_printf;
ctx.base.indentation = 0;
ctx.str = str;
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] [PATCH] st/xa: Link with -Wl,-r instead of -r.
- Ursprungligt meddelande - This is required to link with clang: /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00400160. --- src/gallium/state_trackers/xa/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/state_trackers/xa/Makefile b/src/gallium/state_trackers/xa/Makefile index b42e619..9a822a0 100644 --- a/src/gallium/state_trackers/xa/Makefile +++ b/src/gallium/state_trackers/xa/Makefile @@ -39,7 +39,7 @@ default: $(XA_LIB_NAME) # Make the library $(XA_LIB_NAME): depend $(OBJECTS) - $(CC) -r -nostdlib -o $(XA_LIB_NAME) $(OBJECTS) + $(CC) -Wl,-r -nostdlib -o $(XA_LIB_NAME) $(OBJECTS) install: FORCE Looks good, do you have commit access? Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] windows build experience
On 03/04/2012 10:54 PM, john grant wrote: Hello, I wanted to use Mesa on Windows so that I could spend a little less time at the office. I do not have the hardware at home for the GL extensions I want to work with. After several package installations and adjustments to my system PATH to accommodate Mesa's build system, only to see build errors, I have come to the conclusion that it is very difficult to use Mesa on Windows. The number of dependencies required just to build Mesa seems to be the biggest hurdle. I've spent a few days porting the Scons build system to CMake. My idea is that the use of CMake can make building on Windows more natural by generating a build system (IDE project files) that I'm used to. I've used Scons before, but this is my first experience with CMake. CMake seems pretty easy to use, with the exception of working with Lex and Yacc, which I'm not experienced with either. CMake can generate source code as well, so it should be possible to remove the (undocumented) requirements for Flex and Bison. I don't see how CMake would remove the need for Flex/Bison. In an ideal world, the generated IDE project and GNUmake files could be distributed so no one needs to install CMake either. I don't think that's feasible since one of the jobs of CMake, SCons, and autoconf is to determine what libraries/dependencies are present on the build system and generate Makefiles tailored to them. Is the Mesa community interested in a CMake build system? Probably not. We've got autoconf and SCons already. It seems to be the most popular build system these days for cross platform, open source projects. I would be happy to contribute what I've done so far, but the use of Lex and YACC for the glsl support is incomplete. If I can't wrap this up soon, I think I'll just have to leave the CMake system for someone else to complete because life is too short. Is anyone interested in helping me make the build system on Windows (and other platforms) easier to use? If we could simply improve the documentation in this area, that would probably be enough. I've had my windows environment set up here for quite a while so I don't recall the specifics after installing python, scons, flex, bison. But it's been working for a while. I don't have the time right now to recreate things from scratch. If you keep at it, and manage to get things working, please send your notes so that the docs can be improved. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] draw/llvm: fix clipvertex setting up clipmask.
On 03/03/2012 10:55 AM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
We incorrectly setup clipmask for gl_ClipVertex, this fixes the clipmask
setup.
Signed-off-by: Dave Airlieairl...@redhat.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 36 +++
1 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index f0646ac..fd10bf2 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -1041,7 +1041,7 @@ generate_viewport(struct draw_llvm *llvm,
* Returns clipmask as 4xi32 bitmask for the 4 vertices
*/
static LLVMValueRef
-generate_clipmask(struct gallivm_state *gallivm,
+generate_clipmask(struct draw_llvm *llvm,
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
boolean clip_xy,
boolean clip_z,
@@ -1050,13 +1050,17 @@ generate_clipmask(struct gallivm_state *gallivm,
unsigned ucp_enable,
LLVMValueRef context_ptr)
{
+ struct gallivm_state *gallivm = llvm-gallivm;
LLVMBuilderRef builder = gallivm-builder;
LLVMValueRef mask; /* stores the4xi32 clipmasks */
LLVMValueRef test, temp;
LLVMValueRef zero, shift;
LLVMValueRef pos_x, pos_y, pos_z, pos_w;
+ LLVMValueRef cv_x, cv_y, cv_z, cv_w;
LLVMValueRef plane1, planes, plane_ptr, sum;
struct lp_type f32_type = lp_type_float_vec(32);
+ const unsigned pos = draw_current_shader_position_output(llvm-draw);
+ const unsigned cv = draw_current_shader_clipvertex_output(llvm-draw);
mask = lp_build_const_int_vec(gallivm, lp_type_int_vec(32), 0);
temp = lp_build_const_int_vec(gallivm, lp_type_int_vec(32), 0);
@@ -1064,10 +1068,22 @@ generate_clipmask(struct gallivm_state *gallivm,
shift = lp_build_const_int_vec(gallivm, lp_type_int_vec(32), 1);/* 1 1
1 1 */
/* Assuming position stored at output[0] */
I think that comment needs updating/removal. Maybe add a comment
about 'pos' vs 'cv'.
Otherwise, Reviewed-by: Brian Paul bri...@vmware.com
- pos_x = LLVMBuildLoad(builder, outputs[0][0], ); /*x0 x1 x2 x3*/
- pos_y = LLVMBuildLoad(builder, outputs[0][1], ); /*y0 y1 y2 y3*/
- pos_z = LLVMBuildLoad(builder, outputs[0][2], ); /*z0 z1 z2 z3*/
- pos_w = LLVMBuildLoad(builder, outputs[0][3], ); /*w0 w1 w2 w3*/
+ pos_x = LLVMBuildLoad(builder, outputs[pos][0], ); /*x0 x1 x2 x3*/
+ pos_y = LLVMBuildLoad(builder, outputs[pos][1], ); /*y0 y1 y2 y3*/
+ pos_z = LLVMBuildLoad(builder, outputs[pos][2], ); /*z0 z1 z2 z3*/
+ pos_w = LLVMBuildLoad(builder, outputs[pos][3], ); /*w0 w1 w2 w3*/
+
+ if (clip_user cv != pos) {
+ cv_x = LLVMBuildLoad(builder, outputs[cv][0], ); /*x0 x1 x2 x3*/
+ cv_y = LLVMBuildLoad(builder, outputs[cv][1], ); /*y0 y1 y2 y3*/
+ cv_z = LLVMBuildLoad(builder, outputs[cv][2], ); /*z0 z1 z2 z3*/
+ cv_w = LLVMBuildLoad(builder, outputs[cv][3], ); /*w0 w1 w2 w3*/
+ } else {
+ cv_x = pos_x;
+ cv_y = pos_y;
+ cv_z = pos_z;
+ cv_w = pos_w;
+ }
/* Cliptest, for hardwired planes */
if (clip_xy) {
@@ -1137,27 +1153,27 @@ generate_clipmask(struct gallivm_state *gallivm,
plane_ptr = LLVMBuildGEP(builder, planes_ptr, indices, 3, );
plane1 = LLVMBuildLoad(builder, plane_ptr, plane_x);
planes = vec4f_from_scalar(gallivm, plane1, plane4_x);
- sum = LLVMBuildFMul(builder, planes, pos_x, );
+ sum = LLVMBuildFMul(builder, planes, cv_x, );
indices[2] = lp_build_const_int32(gallivm, 1);
plane_ptr = LLVMBuildGEP(builder, planes_ptr, indices, 3, );
plane1 = LLVMBuildLoad(builder, plane_ptr, plane_y);
planes = vec4f_from_scalar(gallivm, plane1, plane4_y);
- test = LLVMBuildFMul(builder, planes, pos_y, );
+ test = LLVMBuildFMul(builder, planes, cv_y, );
sum = LLVMBuildFAdd(builder, sum, test, );
indices[2] = lp_build_const_int32(gallivm, 2);
plane_ptr = LLVMBuildGEP(builder, planes_ptr, indices, 3, );
plane1 = LLVMBuildLoad(builder, plane_ptr, plane_z);
planes = vec4f_from_scalar(gallivm, plane1, plane4_z);
- test = LLVMBuildFMul(builder, planes, pos_z, );
+ test = LLVMBuildFMul(builder, planes, cv_z, );
sum = LLVMBuildFAdd(builder, sum, test, );
indices[2] = lp_build_const_int32(gallivm, 3);
plane_ptr = LLVMBuildGEP(builder, planes_ptr, indices, 3, );
plane1 = LLVMBuildLoad(builder, plane_ptr, plane_w);
planes = vec4f_from_scalar(gallivm, plane1, plane4_w);
- test = LLVMBuildFMul(builder, planes, pos_w, );
+ test = LLVMBuildFMul(builder, planes, cv_w, );
sum = LLVMBuildFAdd(builder, sum, test, );
test = lp_build_compare(gallivm, f32_type, PIPE_FUNC_GREATER, zero,
sum);
@@ -1389,7 +1405,7 @@
Re: [Mesa-dev] [PATCH 2/3] draw/llvm: fix storing of clipvertex and positions into pre_clip_pos
On 03/03/2012 10:55 AM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
This fixes the rest of the piglit clipvertex tests.
Signed-off-by: Dave Airlieairl...@redhat.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index fd10bf2..5e7fd18 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -899,7 +899,7 @@ static void
store_clip(struct gallivm_state *gallivm,
LLVMValueRef io_ptr,
LLVMValueRef (*outputs)[TGSI_NUM_CHANNELS],
- boolean pre_clip_pos)
+ boolean pre_clip_pos, int idx)
A comment indicating what idx is would be good.
Otherwise, Reviewed-by: Brian Paul bri...@vmware.com
{
LLVMBuilderRef builder = gallivm-builder;
LLVMValueRef out[4];
@@ -918,10 +918,10 @@ store_clip(struct gallivm_state *gallivm,
indices[0] =
indices[1] = lp_build_const_int32(gallivm, 0);
- out[0] = LLVMBuildLoad(builder, outputs[0][0], ); /*x0 x1 x2 x3*/
- out[1] = LLVMBuildLoad(builder, outputs[0][1], ); /*y0 y1 y2 y3*/
- out[2] = LLVMBuildLoad(builder, outputs[0][2], ); /*z0 z1 z2 z3*/
- out[3] = LLVMBuildLoad(builder, outputs[0][3], ); /*w0 w1 w2 w3*/
+ out[0] = LLVMBuildLoad(builder, outputs[idx][0], ); /*x0 x1 x2 x3*/
+ out[1] = LLVMBuildLoad(builder, outputs[idx][1], ); /*y0 y1 y2 y3*/
+ out[2] = LLVMBuildLoad(builder, outputs[idx][2], ); /*z0 z1 z2 z3*/
+ out[3] = LLVMBuildLoad(builder, outputs[idx][3], ); /*w0 w1 w2 w3*/
io0_ptr = LLVMBuildGEP(builder, io_ptr,ind0, 1, );
io1_ptr = LLVMBuildGEP(builder, io_ptr,ind1, 1, );
@@ -1246,6 +1246,8 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
variant-key.clip_z ||
variant-key.clip_user;
LLVMValueRef variant_func;
+ const unsigned pos = draw_current_shader_position_output(llvm-draw);
+ const unsigned cv = draw_current_shader_clipvertex_output(llvm-draw);
arg_types[0] = get_context_ptr_type(llvm); /* context */
arg_types[1] = get_vertex_header_ptr_type(llvm); /* vertex_header */
@@ -1399,8 +1401,8 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
variant-key.clamp_vertex_color);
/* store original positions in clip before further manipulation */
- store_clip(gallivm, io, outputs, 0);
- store_clip(gallivm, io, outputs, 1);
+ store_clip(gallivm, io, outputs, 0, cv);
+ store_clip(gallivm, io, outputs, 1, pos);
/* do cliptest */
if (enable_cliptest) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] draw/llvm: add clip distance support
On 03/03/2012 10:55 AM, Dave Airlie wrote: From: Dave Airlieairl...@redhat.com This add clipdistance support like the non-llvm draw paths, if we have a clip distance we compare with it instead of doing the dot4. We also have to put the have_clipvertex bit into the emitted vertex header. Fixes vs-clip-distance-all-planes-enabled, vs-clip-distance-const-reject, vs-clip-distance-enables, vs-clip-distance-implicitly-sized, vs-clip-distance-in-param, vs-clip-distance-uint-index. Signed-off-by: Dave Airlieairl...@redhat.com 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] [PATCH] gallium: add llvm-related TODOs.
On 03/04/2012 06:57 AM, Dave Airlie wrote: From: Dave Airlieairl...@redhat.com This is just a simple text file containing a list of goals for gallivm/llvmpipe and some info on what is required to get there along with some info on who is looking at things. Signed-off-by: Dave Airlieairl...@redhat.com --- src/gallium/docs/llvm-todo.txt | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) create mode 100644 src/gallium/docs/llvm-todo.txt diff --git a/src/gallium/docs/llvm-todo.txt b/src/gallium/docs/llvm-todo.txt new file mode 100644 index 000..79f93e5 --- /dev/null +++ b/src/gallium/docs/llvm-todo.txt @@ -0,0 +1,19 @@ +TODO covering gallivm/llvmpipe +== + +Goal: GL3.0 support in llvmpipe +--- + +TXQ opcode support - airlied WIP +TXF opcode support. +Integer texture fetch support +Integer renderbuffer support +Vertex ID support. +EXT_transform_feedback support - airlied WIP +clip distance support - airlied WIP +vertex clip support - airlied WIP + +Goal: Other missing extensions compared to softpipe: + +EXT_timer_query - airlied posted a patch + 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] [PATCH 1/9] st/vdpau: implement support for extra mixer layers
On Sun, 04 Mar 2012 11:52:36 -, Christian König deathsim...@vodafone.de wrote: Signed-off-by: Christian König deathsim...@vodafone.de --- src/gallium/state_trackers/vdpau/mixer.c | 27 +-- 1 files changed, 21 insertions(+), 6 deletions(-) Hello Christian Would you consider pushing patches into a branch at fd.o IMHO it would make testing a bit easier Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: Check vs and fs pointer when updating states.
On 03/03/2012 04:17 AM, Vic Lee wrote: This patch fix segfault if an application clears a render target before setting any vertex or fragment shaders, which is a legal situation. I can't seem to trigger this problem with a test program. Can you post a test case? The first part of your patch looks OK but I don't see why the second part is needed. We already check svga-curr.fs before dereffing the pointer. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix an issue with texture border in strip_texture_border()
On 03/01/2012 03:37 PM, Anuj Phogat wrote: Border only applies to the width for a 1D texture array and for 2D texture array it applies to the width and height but not to the depth. This was not handled correctly in strip_texture_border(). v2: height is also affected by border if target is GL_TEXTURE_3D v3: simplified the logic to strip texture dimensions: As the legal_teximage_target() is called earlier in teximage() function, we don't need to repeat that here. Also assuming that strip_texture_border() will not be used for proxy textures otherwise we have to include proxy targets as well. Note: This is a candidate for stable branches Signed-off-by: Anuj Phogatanuj.pho...@gmail.com Did you see the version that I posted? I think it was a little cleaner than your patch. What do you think? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] configure: Fix egl compilation without x11 headers
On 03/05/2012 12:00 PM, Benjamin Franzke wrote: 2012/3/1 Chad Versace chad.vers...@linux.intel.com: On 03/01/2012 11:39 AM, Benjamin Franzke wrote: 2012/3/1 Chad Versace chad.vers...@linux.intel.com: On 02/29/2012 07:36 AM, Benjamin Franzke wrote: We dont want eglplatform.h to typedef egl native types to x11 types, when x11 headers are not available. --- configure.ac |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 0caa1b1..92a0e52 100644 --- a/configure.ac +++ b/configure.ac @@ -1402,6 +1402,10 @@ if test x$enable_egl = xyes; then AC_CHECK_FUNC(mincore, [DEFINES=$DEFINES -DHAVE_MINCORE]) +if test $have_x != yes; then +DEFINES=$DEFINES -DMESA_EGL_NO_X11_HEADERS +fi + if test $enable_static != yes; then # build egl_glx when libGL is built if test x$enable_glx = xyes; then After examining the where the macro is used, in eglplatform.h ... --- snip --- #elif defined(__unix__) #ifdef MESA_EGL_NO_X11_HEADERS typedef void*EGLNativeDisplayType; typedef khronos_uint32_t EGLNativePixmapType; typedef khronos_uint32_t EGLNativeWindowType; #else /* X11 (tentative) */ #include X11/Xlib.h #include X11/Xutil.h typedef Display *EGLNativeDisplayType; typedef Pixmap EGLNativePixmapType; typedef Window EGLNativeWindowType; #endif /* MESA_EGL_NO_X11_HEADERS */ --- end snip --- I can't think of a valid reason for the #else branch to ever be taken. If you're building EGL on Unix/Linux, but not for gbm (__GBM__), Android (ANDRDOID), Wayland (WL_EGL_PLATFORM), or X (the default), then for what platform are you building libEGL? (The question is not rhetorical). The platform headers for wayland/gbm are not included when compiling src/egl/main/* or some other common code in st/egl, that is when the else branch is taken. So currently we include Xlib.h when building without x11 platform, that fails if its not available. Will add a note to the commit message. It appears that the patch may introduce a bug in the 64-bit build of libEGL, but I'm not certain. Here's my reasoning. 1. Suppose that - This patch is applied. - The system has no X headers installed. - Some Wayland application has a source file, broken.c, that #includes wayland-egl.h then EGL/egl.h. 2. In eglapi.c, which defines eglCreateWindowSurface, EGLNativeWindowType will be defined as khronos_uint32_t. 3. In broken.c, wayland-egl.h first defines WL_EGL_PLATFORM. Then EGLNativeWindowType will be defined as wl_egl_window*, a 64-bit type. Yes, thanks for pointing that out. We should just typedef them to khronos_uintptr_t instead. Ok, if we do that, then I like this patch. Without the patch, eglapi.c safely typedefs EGLNativeWindowType to XID, which matches the system's pointer size. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glx: Hook up the unit tests again using the internal gtest.
--- configure.ac | 14 +- src/glx/.gitignore|1 + src/glx/Makefile.am |9 ++--- tests/glx/Makefile.am |8 +--- 4 files changed, 13 insertions(+), 19 deletions(-) diff --git a/configure.ac b/configure.ac index ce48c81..0cdd17d 100644 --- a/configure.ac +++ b/configure.ac @@ -82,18 +82,6 @@ solaris*) ;; esac -AC_PATH_PROG([GTESTCONFIG], [gtest-config]) -if test x$GTESTCONFIG != x; then -GTEST_CFLAGS=`gtest-config --cppflags --cxxflags` -GTEST_LIBS=`gtest-config --ldflags --libs` -AC_SUBST([GTEST_CFLAGS]) -AC_SUBST([GTEST_LIBS]) -HAVE_GTEST=yes -else -HAVE_GTEST=no -fi -AM_CONDITIONAL(HAVE_GTEST, test x$HAVE_GTEST = xyes) - dnl clang is mostly GCC-compatible, but its version is much lower, dnl so we have to check for it. AC_MSG_CHECKING([if compiling with clang]) @@ -793,7 +781,7 @@ dnl dnl this variable will be prepended to SRC_DIRS and is not exported CORE_DIRS= -SRC_DIRS= +SRC_DIRS=gtest GLU_DIRS=sgi GALLIUM_DIRS=auxiliary drivers state_trackers GALLIUM_TARGET_DIRS= diff --git a/src/glx/.gitignore b/src/glx/.gitignore index ea7b611..0706311 100644 --- a/src/glx/.gitignore +++ b/src/glx/.gitignore @@ -3,3 +3,4 @@ Makefile Makefile.in libGL.la +libglx.la diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index b5bbebd..f2ac4ef 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -55,7 +55,9 @@ lib_LTLIBRARIES = \ $(NORMAL_GL_LIB) \ $(MANGLED_GL_LIB) -GL_FILES = \ +noinst_LTLIBRARIES = libglx.la + +libglx_la_SOURCES = \ clientattrib.c \ clientinfo.c \ compsize.c \ @@ -96,6 +98,7 @@ GL_FILES = \ applegl_glx.c GL_LIBS = \ + libglx.la \ $(SHARED_GLAPI_LIBS) \ $(GLAPI_LIB) \ $(GL_LIB_DEPS) @@ -103,8 +106,8 @@ GL_LIBS = \ GL_LDFLAGS = \ -version-number 1:2 -libGL_la_SOURCES = $(GL_FILES) -libMangledGL_la_SOURCES = $(GL_FILES) +libGL_la_SOURCES = +libMangledGL_la_SOURCES = libGL_la_LIBADD = $(GL_LIBS) libMangledGL_la_LIBADD = $(GL_LIBS) libGL_la_LDFLAGS = $(GL_LDFLAGS) diff --git a/tests/glx/Makefile.am b/tests/glx/Makefile.am index cdebf5d..b5cc0b0 100644 --- a/tests/glx/Makefile.am +++ b/tests/glx/Makefile.am @@ -3,7 +3,6 @@ AM_CFLAGS = -I$(top_builddir)/src/glx -I$(top_builddir)/src/mapi \ AM_CXXFLAGS = -I$(top_builddir)/src/glx -I$(top_builddir)/src/mapi \ $(X11_CFLAGS) $(GTEST_CFLAGS) -if HAVE_GTEST if HAVE_XCB_GLX_CREATE_CONTEXT TESTS = glx_unittest check_PROGRAMS = glx_unittest @@ -13,6 +12,9 @@ glx_unittest_SOURCES =\ create_context_unittest.cpp\ fake_glx_screen.cpp -glx_unittest_LDADD = $(top_builddir)/src/glx/libglx.a $(GTEST_LIBS) -lgtest_main -endif +glx_unittest_LDADD = \ + $(top_builddir)/src/glx/libglx.la \ + $(top_builddir)/src/gtest/libgtest.la \ + -lpthread + endif -- 1.7.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] gtest: Build as a convenience library.
--- configure.ac |1 + src/gtest/.gitignore |5 + src/gtest/Makefile.am | 38 ++ 3 files changed, 44 insertions(+), 0 deletions(-) create mode 100644 src/gtest/.gitignore create mode 100644 src/gtest/Makefile.am diff --git a/configure.ac b/configure.ac index a2d906a..ce48c81 100644 --- a/configure.ac +++ b/configure.ac @@ -1961,6 +1961,7 @@ AC_CONFIG_FILES([configs/autoconf src/egl/wayland/wayland-egl/wayland-egl.pc src/egl/wayland/wayland-drm/Makefile src/glx/Makefile + src/gtest/Makefile src/mesa/drivers/dri/dri.pc src/mesa/drivers/dri/Makefile src/mesa/drivers/dri/common/Makefile diff --git a/src/gtest/.gitignore b/src/gtest/.gitignore new file mode 100644 index 000..acf7b5f --- /dev/null +++ b/src/gtest/.gitignore @@ -0,0 +1,5 @@ +.deps +.libs +Makefile +Makefile.in +libgtest.la diff --git a/src/gtest/Makefile.am b/src/gtest/Makefile.am new file mode 100644 index 000..954d4c2 --- /dev/null +++ b/src/gtest/Makefile.am @@ -0,0 +1,38 @@ + # Copyright © 2012 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the Software), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. + +AM_CFLAGS = $(DEFINES) + +lib_LTLIBRARIES = libgtest.la + +libgtest_la_SOURCES = \ + src/gtest-all.cc \ + src/gtest_main.cc + +EXTRA_DIST = \ + src/gtest.cc \ + src/gtest-death-test.cc \ + src/gtest-filepath.cc \ + src/gtest-internal-inl.h \ + src/gtest-port.cc \ + src/gtest-printers.cc \ + src/gtest-test-part.cc \ + src/gtest-typed-test.cc -- 1.7.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] glx: Convert to automake.
On Thu, 1 Mar 2012 19:18:50 +0100, Marek Olšák mar...@gmail.com wrote: On Thu, Mar 1, 2012 at 5:28 PM, Eric Anholt e...@anholt.net wrote: On Thu, 1 Mar 2012 16:50:40 +0100, Marek Olšák mar...@gmail.com wrote: Hi Eric, this commit breaks StarCraft II running on Wine traced by apitrace on r600g. Wine is most probably stuck in a deadlock. It prints these error messages: err:seh:setup_exception_record stack overflow 2412 bytes in thread 0024 eip 00437fdb esp 00c409c4 stack 0xc4-0xc41000-0xd4 err:ntdll:RtlpWaitForCriticalSection section 0x7dce41e0 x11drv_main.c: X11DRV_CritSection wait timed out in thread 0025, blocked by 0024, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x72e200 ? wait timed out in thread 0023, blocked by 0024, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x72e200 ? wait timed out in thread 0009, blocked by 0024, retrying (60 sec) etc. Reverting this commit (and also the egl automake commits to avoid conflicts) fixes the issue. Do you have any idea about what might have gone wrong? Hmm, weird. Defines were my first idea, the diff of all defines used in the compile is: [...] Could you stick a debugger on it and see where it's stopped, at least? Sorry, I haven't been able to obtain a useful backtrace from wine. I have no idea how to debug this. Just to be clear: Is the failure mode only when apitracing wine, and not when running wine standalone or when running glretrace of any resulting trace? Does it require SC2, or can other apps be used to reproduce the failure? Any freely downloadable apps by chance? (That said, wine appears to be totally hosed for me currently, on 8.0 or master, with a segfault almost all the time due to a missing buffer object for one of my winsys renderbuffers) pgp1RT0VwvWlf.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
On Sat, 3 Mar 2012 13:21:08 -0800, Alon Zakai alonza...@gmail.com wrote: Hi everyone, In the project I work on (Emscripten, an open source C/C++ to JavaScript compiler that utilizes LLVM), we want to be able to compile OpenGL games from desktop so that they work on WebGL on the web. The main remaining difficulty for us is to emulate the full OpenGL API using the WebGL API. WebGL is close to OpenGL ES 2.0, so it has shaders but lacks the fixed-function pipeline, glBegin etc. So far we have some of the OpenGL ES 2.0 API implemented, you can see a demo of it on the web here: http://people.mozilla.org/~eakhgari/es2gears.html We are looking for the best way to implement the OpenGL API using the WebGL API, which is basically the problem of implementing OpenGL on top of OpenGL ES 2.0. Note that there is no problem with the fact that WebGL is a JavaScript API, it would be enough to implement OpenGL on OpenGL ES 2.0 in normal C/C++ code; we can automatically compile that code into JavaScript. There are several commercial products doing things of that nature, one of the approaches seems to involve implementing a virtual OpenGL driver, basically a driver that implements the OpenGL API and internally uses OpenGL ES 2.0 to actually render. Since Mesa implements OpenGL drivers, I was wondering if there is some way for us to build on the Mesa code in order to do that? Basically, if we had an implementation of the full OpenGL API in C or C++, that we could in a reasonable way get to utilize OpenGL ES 2.0 as its backend, that would be what we are looking for. Advice on the feasibility of that with Mesa would be very welcome! Kind of an amazing demo. That must have been a lot of work. We were chatting about it here, and it seems like there are a few hard things to handle: 1) Deprecated OpenGL functionality Desktop GL includes ridiculous things like texture borders and GL_CLAMP and glDrawPixels and other things we all wish we could just forget about. ES2 doesn't have those equivalents, so you'd have to emulate them. For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) 2) Desktop GL functionality that only exists as extensions in ES2. As far as I know, you don't get bindings for things like 3D textures in WebGL, even if there's an OES extension for it. This seems hard, without extending WebGL. 3) Converting GLSL 1.10 or 1.20 shaders to GLSL 1.00. I think these are just a matter of transforming the language -- not particularly differences in what features are exposed (other than 3d textures). You might want to take advantage of the GLSL-to-GLSL compiler at https://github.com/aras-p/glsl-optimizer to do this job by tweaking what the backend spits out. To solve these, I don't think building a Mesa driver would help you too much -- it seems like a big detour to mostly get to the same point of hooking desktop glBlendFunc up to WebGL glBlendFunc and so on (git grep ctx-\API suggests not too many overrides are needed). Oh, there are a bunch of cases of desktop GL having multiple names for the same function call (like you'll find in ES once you go poking around their extensions), which you want to map to core ES2 functionality. You may find the alias information Mesa's XML description of the GL API useful for that purpose. Paul Berry's been working on writing a layer to do this job for the piglit test suite recently using the Mesa XML (http://lists.freedesktop.org/archives/piglit/2012-March/001950.html) pgpBoqTCheyfj.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
- Original Message - On Sat, 3 Mar 2012 13:21:08 -0800, Alon Zakai alonza...@gmail.com wrote: Hi everyone, In the project I work on (Emscripten, an open source C/C++ to JavaScript compiler that utilizes LLVM), we want to be able to compile OpenGL games from desktop so that they work on WebGL on the web. The main remaining difficulty for us is to emulate the full OpenGL API using the WebGL API. WebGL is close to OpenGL ES 2.0, so it has shaders but lacks the fixed-function pipeline, glBegin etc. So far we have some of the OpenGL ES 2.0 API implemented, you can see a demo of it on the web here: http://people.mozilla.org/~eakhgari/es2gears.html We are looking for the best way to implement the OpenGL API using the WebGL API, which is basically the problem of implementing OpenGL on top of OpenGL ES 2.0. Note that there is no problem with the fact that WebGL is a JavaScript API, it would be enough to implement OpenGL on OpenGL ES 2.0 in normal C/C++ code; we can automatically compile that code into JavaScript. There are several commercial products doing things of that nature, one of the approaches seems to involve implementing a virtual OpenGL driver, basically a driver that implements the OpenGL API and internally uses OpenGL ES 2.0 to actually render. Since Mesa implements OpenGL drivers, I was wondering if there is some way for us to build on the Mesa code in order to do that? Basically, if we had an implementation of the full OpenGL API in C or C++, that we could in a reasonable way get to utilize OpenGL ES 2.0 as its backend, that would be what we are looking for. Advice on the feasibility of that with Mesa would be very welcome! Kind of an amazing demo. That must have been a lot of work. We were chatting about it here, and it seems like there are a few hard things to handle: 1) Deprecated OpenGL functionality This part 1) is where we need to focus, as the other parts seem less concerning for porting real-world games (I elaborate below). Desktop GL includes ridiculous things like texture borders and GL_CLAMP and glDrawPixels and other things we all wish we could just forget about. ES2 doesn't have those equivalents, so you'd have to emulate them. That's exactly where we were hoping that Mesa might be able to help: doesn't Mesa already have an implementation of these OpenGL 1 pieces on top of something closer to OpenGL ES 2 (which IIUC is far closer to how modern hardware really works)? If Mesa had an implementation of GL1 on top of GLES2, Emscripten (Alon's C/C++-to-JS translator) could compile it to JS. For a bunch of it, apps don't use it so nobody would notice. glBitmap and glDrawPixels are reasonably popular, though. You should be able to build those with shaders, though. You can see partial implementations for these in on top of fixed function in Mesa as src/mesa/drivers/common/meta.c (contributions welcome, particularly in the form of GLSL-based implementations of them!) Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-) Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement: - glBegin ... glVertex ... glEnd - glShadeModel(GL_FLAT) (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!) - display lists - the lighting model (glLight, glMaterial) Does Mesa have code that could be reused to implement some of that on top of ES2? 2) Desktop GL functionality that only exists as extensions in ES2. I wouldn't worry about that for now. For the time being, we'd be very happy if we could compile, say, Quake 3 to WebGL. In other words, there's a lot that can be done before we'd have to worry about functionality that requires more ES2 extensions. As far as I know, you don't get bindings for things like 3D textures in WebGL, even if there's an OES extension for it. This seems hard, without extending WebGL. 3D textures haven't been made a WebGL extension because they seem relatively little used, the applications that really need them in WebGL (medical visualization) have successfully been emulating them with large 2D textures and a smart fragment shader, and the benefit of exposing real 3D textures seems not sufficient to justify the portability regression they would introduce (since content requiring 3D textures would not run on hardware that doesn't support them). 3) Converting GLSL 1.10 or 1.20 shaders to GLSL 1.00. I think these are just a matter of transforming the language -- not particularly differences in what features are exposed (other than 3d textures). You might want to take advantage of the GLSL-to-GLSL compiler at https://github.com/aras-p/glsl-optimizer to do this job by tweaking what the backend spits out. We already have a GLSL-to-GLSL compiler provided by ANGLE, so we
Re: [Mesa-dev] [PATCH] mesa: handle array textures in strip_texture_border()
On Wed 29 Feb 2012 07:36:21 PM PST, Brian Paul wrote:
If the texture is a 1D array, don't remove the border pixel from the
height. Similarly for 2D array textures and the depth direction.
Simplify the function by assuming the border is always one pixel.
---
src/mesa/main/teximage.c | 37 -
1 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4fb81e6..29d1d36 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2422,7 +2422,7 @@ _mesa_choose_texture_format(struct gl_context *ctx,
/**
* Adjust pixel unpack params and image dimensions to strip off the
- * texture border.
+ * one-pixel texture border.
*
* Gallium and intel don't support texture borders. They've seldem been used
* and seldom been implemented correctly anyway.
@@ -2430,34 +2430,37 @@ _mesa_choose_texture_format(struct gl_context *ctx,
* \param unpackNew returns the new pixel unpack parameters
*/
static void
-strip_texture_border(GLint *border,
+strip_texture_border(GLenum target,
GLint *width, GLint *height, GLint *depth,
const struct gl_pixelstore_attrib *unpack,
struct gl_pixelstore_attrib *unpackNew)
{
- assert(*border 0); /* sanity check */
+ assert(width);
+ assert(height);
+ assert(depth);
*unpackNew = *unpack;
if (unpackNew-RowLength == 0)
unpackNew-RowLength = *width;
- if (depth unpackNew-ImageHeight == 0)
+ if (unpackNew-ImageHeight == 0)
unpackNew-ImageHeight = *height;
- unpackNew-SkipPixels += *border;
- if (height)
- unpackNew-SkipRows += *border;
- if (depth)
- unpackNew-SkipImages += *border;
-
assert(*width = 3);
- *width = *width - 2 * *border;
- if (height *height = 3)
- *height = *height - 2 * *border;
- if (depth *depth = 3)
- *depth = *depth - 2 * *border;
- *border = 0;
+ unpackNew-SkipPixels++; /* skip the border */
+ *width = *width - 2; /* reduce the width by two border pixels */
+
+ /* The min height of a texture with a border is 3 */
+ if (*height = 3 target != GL_TEXTURE_1D_ARRAY) {
+ unpackNew-SkipRows++; /* skip the border */
+ *height = *height - 2; /* reduce the height by two border pixels */
+ }
+
+ if (*depth = 3 target != GL_TEXTURE_2D_ARRAY) {
+ unpackNew-SkipImages++; /* skip the border */
+ *depth = *depth - 2; /* reduce the depth by two border pixels */
+ }
}
/**
@@ -2542,7 +2545,7 @@ teximage(struct gl_context *ctx, GLuint dims,
* rarely-tested software fallback rendering.
*/
if (border ctx-Const.StripTextureBorder) {
- strip_texture_border(border, width, height, depth, unpack,
+ strip_texture_border(target, width, height, depth, unpack,
unpack_no_border);
border value should be set to zero after this call. I'm getting
assertion failure in piglit
texture-border test (under review) without that:
texture-border: intel_tex.c:64: intel_alloc_texture_image_buffer:
Assertion `image-Border == 0' failed.
unpack = unpack_no_border;
}
Apart from above issue this patch looks cleaner than mine.
After above fix this patch is:
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1.
llvm-3.1svn r152043 changes createMCInstPrinter to take an additional
MCRegisterInfo argument.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
index 11209da..b6849cb 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
@@ -243,7 +243,18 @@ lp_disassemble(const void* func)
int AsmPrinterVariant = AsmInfo-getAssemblerDialect();
#endif
-#if HAVE_LLVM = 0x0300
+#if HAVE_LLVM = 0x0301
+ OwningPtrconst MCRegisterInfo MRI(T-createMCRegInfo(Triple));
+ if (!MRI) {
+ debug_printf(error: no register info for target %s\n, Triple.c_str());
+ return;
+ }
+#endif
+
+#if HAVE_LLVM = 0x0301
+ OwningPtrMCInstPrinter Printer(
+ T-createMCInstPrinter(AsmPrinterVariant, *AsmInfo, *MRI, *STI));
+#elif HAVE_LLVM == 0x0300
OwningPtrMCInstPrinter Printer(
T-createMCInstPrinter(AsmPrinterVariant, *AsmInfo, *STI));
#elif HAVE_LLVM = 0x0208
--
1.7.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915: move the FALLBACK_DRAW_OFFSET check outside the drawing rect check
We have to do fallback when the 'Clipped Drawing Rectangle X/Y Max'
exceed the hardware's limit no matter the drawing rectangle offset
changed or not.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46665
NOTE: This is a candidate for stable release branches.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/drivers/dri/i915/i915_vtbl.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index 11e8a35..e78dbc8 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -665,12 +665,11 @@ i915_set_draw_region(struct intel_context *intel,
draw_offset = (draw_y 16) | draw_x;
+ FALLBACK(intel, I915_FALLBACK_DRAW_OFFSET,
+(ctx-DrawBuffer-Width + draw_x 2048) ||
+(ctx-DrawBuffer-Height + draw_y 2048));
/* When changing drawing rectangle offset, an MI_FLUSH is first required. */
if (draw_offset != i915-last_draw_offset) {
- FALLBACK(intel, I915_FALLBACK_DRAW_OFFSET,
- (ctx-DrawBuffer-Width + draw_x 2048) ||
- (ctx-DrawBuffer-Height + draw_y 2048));
-
state-Buffer[I915_DESTREG_DRAWRECT0] = MI_FLUSH |
INHIBIT_FLUSH_RENDER_CACHE;
i915-last_draw_offset = draw_offset;
} else
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
