[Mesa-dev] [ANNOUNCE] mesa-demos 8.1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 New release of mesa demos repo (8.1.0). I'm mainly releasing this to pick up the newer glxinfo changes for core profiles. But apparantly we haven't released in ages so the log is below! Dave. Aaron Plattner (1): glxgears: Honor -fullscreen in initial reshape Alan Coopersmith (1): Allow builders to specify GLEW_CFLAGS GLEW_LIBS Alex Wu (2): eglut: Add wayland support opengles2: Add es2gears_wayland target Alexandre Demers (1): glxinfo: add -s flag to print one extension per line Andreas Boll (4): index.html: upgrade from legacy html to HTML 4.01 strict build: add 'component=Demos' to bugzilla link demos: add missing binaries to .gitignore build: require glew 1.5.4 Benjamin Franzke (3): eglkms: Use gbm instead of EGL_MESA_drm_image eglkms: Destroy resources eglkms: Restore saved crtc Brian (1): xdemos: fix a bunch of unused variable warnings Brian Paul (77): updated docs with prerequisites such as glew 1.5.4 or later fp-tri: initialize the texture uniforms trivial: added tri-tex-1d.c test stex3d: print 'f' key info textures: added another filter mode arbocclude2: assorted clean-ups, indenting, etc pointcoord: use 'o' key to toggle point sprite origin spriteblast: added fragment program option openvg: add lion-render.h to SOURCES line-xor: test line drawing in XOR mode mipmap_tunnel: new test to examine mipmap filtering rename clear.c to clear-color.c tri-edgeflag-array: test glEdgeFlagPointer() stex3d: added out-of-memory error checks glxinfo: check for extension support before querying limits shadow_sampler: probe/print pixel value, fix GL version check egl: add compile-time extension checking, use eglGetProcAddress fire: call glutDestroyWindow() simplex-noise: test of GLSL webgl-noise noise2: reindent shader for simplex-noise.c demo tests/shader-interp: convert perspective interpolation to linear shader-interp: don't rely on gl_FragCoord.w util: add LinkShaders3() geom-wide-lines, geom-sprites - geometry shader demos shadow-sample: an old GLSL shadow sampler test drawstencil: test writing stencil image with fragment shader geom-wide-lines: add keys to toggle GS on/off, line width geom-sprites: remove dead code, some clean-ups geom-stipple-lines: do line stipple with geometry/fragment shaders arbocclude2: silence some warnings sotest: silence warnings vstest: silence warnings slang/Makefile: add src/util include path bezier: check for GL_ARB_geometry_shader4 extension vp-tris: use larger buffer to handle longer programs mipmap_tunnel: add support for GL_EXT_texture_filter_anisotropic glxinfo: minor whitespace fixes glxinfo: use X Bool, True, False everywhere to be consistent cuberender: demo rendering to cube map faces for environment mapping cuberender: set texture wrap mode to GL_CLAMP_TO_EDGE tests/clip: a simple interactive clipping test trivial/tri-edgeflag-pv: test provoking vertex effect on edge flags linehacks: do stipple, wide, smooth lines with hacks viewmemory: view uninitialized video memory point-sprite: clean-up, set GL_COORD_REPLACE_ARB mode redbook: add missing progs to Makefile.am polys: destroy window before exiting tri-2101010: include glut_wrap.h as other demos do glinfo: query/print GL_SHADING_LANGUAGE_VERSION mipmap_limits: print current params on screen mipmap_limits: fix keyboard info string glxinfo: query/print GL_ARB_framebuffer_object limits wglinfo: query/print GL_ARB_framebuffer_object limits util: add gl_wrap.h and glu_wrap.h to libutil_la_SOURCES util: add GL_FLOAT_MAT4 support, more sampler types shtest: fix docs and code with respect to var names and types geom-outlining: add demo of polygon outlining with a geometry shader rubberband: add a glFlush() call to display the front-buffer drawing fp-tri: s/Display/Draw/ to avoid collision with X Display glsl/identity: clean out unused code arbfslight: re-indent the code trivial: set glClearColor alpha=1.0 glsl/identity: remove more unused stuff cubemap: add some fflush(stdout) calls for Windows mipmap_limits: add some fflush(stdout) calls for Windows clear-fbo: clean-up the code, print pixel color for debugging clear-fbo: call fflush(stdout) for Windows add missing programs to trivial/Makefile.am geom-stipple-lines: use a float[16] uniform for the pattern line-smooth: add flat/smooth shading control shtest: allow compiling only a VS or only a FS trivial/tri-z-clip: test near/far triangle clipping glxinfo: add support for creating/querying core-profile contexts
[Mesa-dev] [Bug 61395] New: glEdgeFlag can't be set to false
https://bugs.freedesktop.org/show_bug.cgi?id=61395 Priority: medium Bug ID: 61395 Assignee: mesa-dev@lists.freedesktop.org Summary: glEdgeFlag can't be set to false Severity: normal Classification: Unclassified OS: Linux (All) Reporter: speed.the.b...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Mesa core Product: Mesa Created attachment 75444 -- https://bugs.freedesktop.org/attachment.cgi?id=75444action=edit test program Setting glEdgeFlag to GL_FALSE, then checking glGetBooleanv of GL_EDGE_FLAG returns GL_TRUE. -- 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 61395] glEdgeFlag can't be set to false
https://bugs.freedesktop.org/show_bug.cgi?id=61395 Blaž Hrastnik speed.the.b...@gmail.com changed: What|Removed |Added CC||speed.the.b...@gmail.com -- 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] r600g: status of my work on the shader optimization
On 02/22/2013 04:35 PM, Henri Verbeet wrote: For what it's worth, I get a number of failures in the Wine d3d9 tests on Cayman with this branch (9219c54b5c5a65c269124637a6e654eda4cdbb8e). I haven't looked at why yet. Unfortunately I have no cayman card to reproduce the issues. I can only test on evergreen, and I don't see any problems with d3d9 tests. On evergreen all known problems are fixed already, and I have to rely on the help of the users to fix remaining issues with other chips. If you'd like to help me with debugging the issues on cayman, then please read the regression debugging section in the r600-sb branch notes [1] (or possibly more up-to-date source here - [2]), it explains how to find the exact shader that causes regression. After locating the guilty shader, you only need to prepend R600_DUMP_SHADERS=2 R600_SB_DUMP=3 to the command line to produce the full dump for that shader, then please send it to me, and I'll do my best to fix the issue. Thanks for testing this branch. Vadim [1]: http://people.freedesktop.org/~vadimg/r600-sb.html [2]: http://cgit.freedesktop.org/~vadimg/mesa/plain/src/gallium/drivers/r600/sb/notes.markdown?h=r600-sb ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/vega: Fix memory leak in combine_shaders.
On 02/23/2013 06:16 PM, Vinson Lee wrote:
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Leev...@freedesktop.org
---
src/gallium/state_trackers/vega/shaders_cache.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/vega/shaders_cache.c
b/src/gallium/state_trackers/vega/shaders_cache.c
index eceae54..c1082ca 100644
--- a/src/gallium/state_trackers/vega/shaders_cache.c
+++ b/src/gallium/state_trackers/vega/shaders_cache.c
@@ -225,8 +225,10 @@ combine_shaders(const struct shader_asm_info
*shaders[SHADER_STAGES], int num_sh
ureg_END(ureg);
shader-tokens = ureg_finalize(ureg);
- if(!shader-tokens)
+ if (!shader-tokens) {
+ ureg_destroy(ureg);
return NULL;
+ }
p = pipe-create_fs_state(pipe, shader);
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] radeonsi: Fix memory leak in si_set_constant_buffer.
On 02/23/2013 06:27 PM, Vinson Lee wrote: Fixes resource leak defect reported by Coverity. Signed-off-by: Vinson Leev...@freedesktop.org --- src/gallium/drivers/radeonsi/si_state.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c index 769ba0c..a395ec4 100644 --- a/src/gallium/drivers/radeonsi/si_state.c +++ b/src/gallium/drivers/radeonsi/si_state.c @@ -2523,6 +2523,7 @@ static void si_set_constant_buffer(struct pipe_context *ctx, uint shader, uint i default: R600_ERR(unsupported %d\n, shader); + FREE(pm4); } if (cb-buffer !=rbuffer-b.b) 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] radeonsi: Fix memory leak in si_set_constant_buffer.
On Sat, Feb 23, 2013 at 8:27 PM, Vinson Lee v...@freedesktop.org wrote: Fixes resource leak defect reported by Coverity. Signed-off-by: Vinson Lee v...@freedesktop.org Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- src/gallium/drivers/radeonsi/si_state.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c index 769ba0c..a395ec4 100644 --- a/src/gallium/drivers/radeonsi/si_state.c +++ b/src/gallium/drivers/radeonsi/si_state.c @@ -2523,6 +2523,7 @@ static void si_set_constant_buffer(struct pipe_context *ctx, uint shader, uint i default: R600_ERR(unsupported %d\n, shader); + FREE(pm4); } if (cb-buffer != rbuffer-b.b) -- 1.8.1.2 ___ 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] r600g: status of my work on the shader optimization
On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote: If you'd like to help me with debugging the issues on cayman, then please read the regression debugging section in the r600-sb branch notes [1] (or possibly more up-to-date source here - [2]), it explains how to find the exact shader that causes regression. After locating the guilty shader, you only need to prepend R600_DUMP_SHADERS=2 R600_SB_DUMP=3 to the command line to produce the full dump for that shader, then please send it to me, and I'll do my best to fix the issue. I briefly looked at it yesterday, but ran out of time. I did find out that all of the failures except one (in loop_index_test()) go away if I skip the if-conversion pass. I have the impression that the PRED_SET* instructions like PRED_SETNE_INT don't behave quite the way the ISA docs claim they do wrt. the value written to the destination register, but instead seem to behave more like the regular SET* instructions in that regard. I didn't properly test this, so it's more of a theory at this point, and may just be wrong. Of course we don't really want to use the PRED_SET* instructions to begin with if we're not going to actually use the predicate, so we'll probably just want to convert them to SET* instructions anyway. Somewhat related to that, wined3d generates GLSL of the form dst = (src0 src1) ? 1.0 : 0.0; for the D3D slt instruction (and similar code for instructions like sge, etc.). The TGSI for that looks pretty awful, first doing a SLT, converting the result to an integer, and then branching on that to assign either 1.0 or 0.0 again. The if-conversion pass is fairly helpful there in the sense that it at least gets rid of the branches, but you still end up with a sequence like SETGE, FLT_TO_INT, PRED_SETNE_INT, CNDE_INT, while all that's really needed is the SETGE. That's probably best addressed in either the GLSL compiler or the GLSL - TGSI stage though. Unfortunately I won't be able to test with that system again until at least Thursday, so it'll be a while before I can actually do anything about it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: status of my work on the shader optimization
On 02/24/2013 11:01 PM, Henri Verbeet wrote: On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote: If you'd like to help me with debugging the issues on cayman, then please read the regression debugging section in the r600-sb branch notes [1] (or possibly more up-to-date source here - [2]), it explains how to find the exact shader that causes regression. After locating the guilty shader, you only need to prepend R600_DUMP_SHADERS=2 R600_SB_DUMP=3 to the command line to produce the full dump for that shader, then please send it to me, and I'll do my best to fix the issue. I briefly looked at it yesterday, but ran out of time. I did find out that all of the failures except one (in loop_index_test()) go away if I skip the if-conversion pass. I have the impression that the PRED_SET* instructions like PRED_SETNE_INT don't behave quite the way the ISA docs claim they do wrt. the value written to the destination register, but instead seem to behave more like the regular SET* instructions in that regard. I didn't properly test this, so it's more of a theory at this point, and may just be wrong. Of course we don't really want to use the PRED_SET* instructions to begin with if we're not going to actually use the predicate, so we'll probably just want to convert them to SET* instructions anyway. Yeah, I see now, I missed the fact that PRED_SETcc instructions on cayman can't be used as simple ALU instructions without side effects, they always update exec_mask. Somewhat related to that, wined3d generates GLSL of the form dst = (src0 src1) ? 1.0 : 0.0; for the D3D slt instruction (and similar code for instructions like sge, etc.). The TGSI for that looks pretty awful, first doing a SLT, converting the result to an integer, and then branching on that to assign either 1.0 or 0.0 again. The if-conversion pass is fairly helpful there in the sense that it at least gets rid of the branches, but you still end up with a sequence like SETGE, FLT_TO_INT, PRED_SETNE_INT, CNDE_INT, while all that's really needed is the SETGE. That's probably best addressed in either the GLSL compiler or the GLSL - TGSI stage though. I just implemented the simplest way of if-conversion for now, but the first thing that I'm going to add to the (currently empty) peephole pass is the optimization of SETcc, PRED_SETcc, etc, including the conversions between float/int bools, to get rid of all unnecessary operations. Unfortunately I won't be able to test with that system again until at least Thursday, so it'll be a while before I can actually do anything about it. Well, I see the problem now, so there is no need for any special testing until I'll implement something to fix it. Anyway, you helped me to understand what's wrong, thanks. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] pipe-loader: Fix out of source build
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de --- src/gallium/targets/opencl/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/opencl/Makefile.am index c5c3003..709112f 100644 --- a/src/gallium/targets/opencl/Makefile.am +++ b/src/gallium/targets/opencl/Makefile.am @@ -32,11 +32,11 @@ libOpenCL_la_SOURCES = # Force usage of a C++ linker nodist_EXTRA_libOpenCL_la_SOURCES = dummy.cpp -PIPE_SRC_DIR = $(top_srcdir)/src/gallium/targets/pipe-loader +PIPE_BUILD_DIR = $(top_builddir)/src/gallium/targets/pipe-loader # Provide compatibility with scripts for the old Mesa build system for # a while by putting a link to the driver into /lib of the build tree. all-local: libOpenCL.la - @$(MAKE) -C $(PIPE_SRC_DIR) + @$(MAKE) -C $(PIPE_BUILD_DIR) $(MKDIR_P) $(top_builddir)/$(LIB_DIR) ln -f .libs/libOpenCL.so* $(top_builddir)/$(LIB_DIR)/ -- 1.8.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] New: glCallLists performance extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=61412 Priority: medium Bug ID: 61412 Assignee: mesa-dev@lists.freedesktop.org Summary: glCallLists performance extremely slow Severity: major Classification: Unclassified OS: Linux (All) Reporter: rexhunte...@gmail.com Hardware: All Status: NEW Version: unspecified Component: Other Product: Mesa When running Carnivores 2 linux port on my Intel chipset (low-performance) the application performs astoundingly well, upwards of 120 fps, 20 more frames than the nvidia high performance card. As soon as I implemented the text support using XFonts and call lists (yes deprecated) I was getting ~8 fps, commented out glCallLists and discovered this was the culprit, the performance slow down was constant from game start to finish. Rebuilt the application for my Windows 7 machine, ran it and had no problems with the WGL version of things, went back to Linux and ran it using only the nvidia drivers and had no performance issues at all. I realise that Lists are outdated and deprecated however I'm building this project for people who still have OpenGL 1.3 and 2.0 devices and have issues with large textures (game is multilingual as well, so bitmap fonts in my own textures would get rather enormous to support everything from Latin to Cyrillic) Not a huge problem since it is deprecated after all but it definitely kills backwards compatibility and totally kills off anyone with a netbook or older device driver. Running the application using GLX/WGL context creation and am able to get a 3.0+ context, however am sticking to the legacy 2.1 and below side of things. List is a standard 256 character font mapping if it helps any. -- 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] pipe-loader: Fix out of source build
On Sun, Feb 24, 2013 at 2:00 PM, Niels Ole Salscheider niels_...@salscheider-online.de wrote: Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de --- src/gallium/targets/opencl/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/opencl/Makefile.am index c5c3003..709112f 100644 --- a/src/gallium/targets/opencl/Makefile.am +++ b/src/gallium/targets/opencl/Makefile.am @@ -32,11 +32,11 @@ libOpenCL_la_SOURCES = # Force usage of a C++ linker nodist_EXTRA_libOpenCL_la_SOURCES = dummy.cpp -PIPE_SRC_DIR = $(top_srcdir)/src/gallium/targets/pipe-loader +PIPE_BUILD_DIR = $(top_builddir)/src/gallium/targets/pipe-loader # Provide compatibility with scripts for the old Mesa build system for # a while by putting a link to the driver into /lib of the build tree. all-local: libOpenCL.la - @$(MAKE) -C $(PIPE_SRC_DIR) + @$(MAKE) -C $(PIPE_BUILD_DIR) $(MKDIR_P) $(top_builddir)/$(LIB_DIR) ln -f .libs/libOpenCL.so* $(top_builddir)/$(LIB_DIR)/ -- 1.8.1.3 I think I've fixed this in a different way (that doesn't involve calling $(MAKE)) in this branch: http://cgit.freedesktop.org/~mattst88/mesa/log/?h=make-dist ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61415] New: Clover ignores --with-opencl-libdir path
https://bugs.freedesktop.org/show_bug.cgi?id=61415
Priority: medium
Bug ID: 61415
Assignee: mesa-dev@lists.freedesktop.org
Summary: Clover ignores --with-opencl-libdir path
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: m...@fireburn.co.uk
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Other
Product: Mesa
When compiling clover an installation directory can be given using
--with-opencl-libdir
This currently doesn't work - I'm guessing it used to and I'm going to hazard a
guess that it was the automake conversion that introduced the issue
Built with
--with-opencl-libdir=${EPREFIX}/usr/$(get_libdir)/OpenCL/vendors/mesa
Expected /usr/lib64/OpenCL/vendors/mesa/libOpenCL.so.1.0.0
Get /usr/lib64/libOpenCL.so.1.0.0
--
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 61416] New: Clover doesn't work on a PRIME system when run under X
https://bugs.freedesktop.org/show_bug.cgi?id=61416 Priority: medium Bug ID: 61416 Assignee: mesa-dev@lists.freedesktop.org Summary: Clover doesn't work on a PRIME system when run under X Severity: normal Classification: Unclassified OS: All Reporter: m...@fireburn.co.uk Hardware: Other Status: NEW Version: git Component: Other Product: Mesa Clover doesn't find the correct device when running the simple tests when run under X ./math-int if_ne -20 20 1 radeon: Failed to get PCI ID, error number -13 There are 1 platforms. clGetDeviceIDs() failed: CL_DEVICE_NOT_FOUND When I run it from a virtual terminal (X is still running) I get: ./math-int if_ne -20 20 1 There are 1 platforms. There are 1 GPU devices. clCreateContext() succeeded. clCreateCommandQueue() succeeded. clCreateProgramWithSource() succeeded. clBuildProgram() succeeded. clCreateKernel() succeeded. clCreateBuffer() succeeded. clSetKernelArg() succeeded. clSetKernelArg() succeeded. clSetKernelArg() succeeded. clEnqueueNDRangeKernel() succeeded. clEnqueueReadBuffer() succeeded. Pass The above was typed manually due to the output not piping to a file - think there are a few typos in the program Is Clover using an environmental variable when run under X that's giving it the wrong device name? This is a PRIME system - sandybridge i965 with Radeon 6600M r600g tau Overlay # lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09) 00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port [8086:0105] (rev 09) 00:01.2 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port [8086:0109] (rev 09) 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 05) 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b5) 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b5) 00:1c.7 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 [8086:1c1e] (rev b5) 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 05) 00:1f.0 ISA bridge [0601]: Intel Corporation HM65 Express Chipset Family LPC Controller [8086:1c49] (rev 05) 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 05) 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 05) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Whistler [AMD Radeon HD 6600M Series] [1002:6741] 09:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6230 [Rainbow Peak] [8086:0090] (rev 34) 0a:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR8151 v2.0 Gigabit Ethernet [1969:1083] (rev c0) 0b:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) -- 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 61416] Clover doesn't work on a PRIME system when run under X
https://bugs.freedesktop.org/show_bug.cgi?id=61416 --- Comment #1 from Mike Lothian m...@fireburn.co.uk --- Created attachment 75466 -- https://bugs.freedesktop.org/attachment.cgi?id=75466action=edit Xorg log -- 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 61416] Clover doesn't work on a PRIME system when run under X
https://bugs.freedesktop.org/show_bug.cgi?id=61416 Mike Lothian m...@fireburn.co.uk changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #2 from Mike Lothian m...@fireburn.co.uk --- Also just found this in my dmesg: [80637.912484] traps: memset[1671] general protection ip:7f720cbd6a68 sp:7fff4301aec0 error:0 in libOpenCL.so.1.0.0[7f720c955000+e8] [80637.931162] traps: memset[1676] general protection ip:7fd72d648a68 sp:7fff95024860 error:0 in libOpenCL.so.1.0.0[7fd72d3c7000+e8] [80638.196478] traps: memset[1736] general protection ip:7fd4f0e24a68 sp:7fffc08321a0 error:0 in libOpenCL.so.1.0.0[7fd4f0ba3000+e8] [80638.213838] traps: memset[1740] general protection ip:7f323c707a68 sp:7fffaa50b780 error:0 in libOpenCL.so.1.0.0[7f323c486000+e8] [80638.230677] traps: memset[1744] general protection ip:7f15cbbcfa68 sp:7fffd6528c20 error:0 in libOpenCL.so.1.0.0[7f15cb94e000+e8] [80638.248368] traps: memset[1748] general protection ip:7f8077aeea68 sp:7fff57009ae0 error:0 in libOpenCL.so.1.0.0[7f807786d000+e8] [80638.299297] traps: memset[1762] general protection ip:7f20cc28ea68 sp:7fff183d62e0 error:0 in libOpenCL.so.1.0.0[7f20cc00d000+e8] [80638.316670] traps: memset[1766] general protection ip:7f133368ba68 sp:7fff058332a0 error:0 in libOpenCL.so.1.0.0[7f133340a000+e8] These don't appear when I run the test above either in X or from the terminal They only appear when I run all the tests under X - 71 fails No messages appear from running from the terminal where I get 67 Passes 4 Fails -- 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 61417] New: Clover doesn't export the OPENCL_1.0 Symbol
https://bugs.freedesktop.org/show_bug.cgi?id=61417 Priority: medium Bug ID: 61417 Assignee: mesa-dev@lists.freedesktop.org Summary: Clover doesn't export the OPENCL_1.0 Symbol Severity: normal Classification: Unclassified OS: All Reporter: m...@fireburn.co.uk Hardware: Other Status: NEW Version: git Component: Other Product: Mesa Clover doesn't export the symbol OPENCL_1.0 which is required by Luxmark ./LuxMark.sh ./luxmark-linux64: /usr/lib64/libOpenCL.so.1: version `OPENCL_1.0' not found (required by ./luxmark-linux64) -- 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 59187] [Steam] Implement GLSL 1.30 (for older chipsets than SandyBridge)
https://bugs.freedesktop.org/show_bug.cgi?id=59187 --- Comment #9 from Chris Forbes chr...@ijw.co.nz --- I'm keen to fix this, I just need to scrounge up a working Ironlake box first. -- 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 61318] Can't compile GLU 32bit on 64bit
https://bugs.freedesktop.org/show_bug.cgi?id=61318 --- Comment #5 from Tapani Pälli lem...@gmail.com --- This sounds to me like a libtool issue, bug #50754 has possible fix you could try for this. -- 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] [RFC] New EGL extension: EGL_EXT_platform_display
On Tue, 19 Feb 2013 08:20:51 -0800 Chad Versace chad.vers...@linux.intel.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm seeking feedback on an EGL extension that I'm drafting. The ideas have already been discussed at Khronos meetings to a good reception, but I want feedback from Mesa developers too. Summary - --- The extension, tentatively named EGL_EXT_platform_display, enables EGL clients to specify to which platform (X11, Wayland, gbm, etc) an EGL resource (EGLDisplay, EGLSurface, etc) belongs when the resource is derived from a platform-native type. As a corollary, the extension enables the creation of EGL resources from different platforms within a single process. Feedback - I'd like to hear feeback about the details below. Do you see any potential problems? Is it lacking a feature that you believe should be present? Details - --- The draft extension defines the following new functions: // This is the extenion's key function. // EGLDisplay eglGetPlatformDisplayEXT(EGLenum platform, void *native_display); // The two eglCreate functions below differ from their core counterparts // only in their signature. The EGLNative types are replaced with void*. // This makes the signature agnostic to which platform the native resource // belongs. EGLSurface eglCreatePlatformWindowSurfaceEXT(EGLDisplay dpy, EGLConfig config, void *native_window, const EGLint *attrib_list); EGLSurface eglCreatePlatformPixmapSurface(EGLDisplay dpy, EGLConfig config, void *native_pixmap, const EGLint *attrib_list); Valid values for `platform` are defined by layered extensions. For example, EGL_EXT_platform_x11 defines EGL_PLATFORM_X11, and EGL_EXT_platform_wayland defines EGL_PLATFORM_WAYLAND. Also, the layered extensions specify which native types should be passed as the native parameters. For example, EGL_EXT_platform_wayland specifies that, when calling eglCreatePlatformWindowSurfaceEXT with a display that was derived from a Wayland display, then the native_window parameter must be `struct wl_egl_window*`. Analogously, EGL_EXT_platform_x11 specifies that native_window must be `Window*`. Example Code for X11 - // The internal representation of the egl_dpy, created below, remembers that // it was derived from an Xlib display. Display *xlib_dpy = XOpenDisplay(NULL); EGLDisplay *egl_dpy = eglGetPlatformDisplayEXT(EGL_PLATFORM_X11, xlib_dpy); EGLConfig config; eglChooseConfig(egl_dpy, config, ...); // Since egl_dpy remembers that it was derived from an Xlib display, when // creating the EGLSurface below libEGL internally casts the // `(void*) xlib_win` to `Window*`. Window xlib_win = XCreateWindow(xlib_dpy, ...); EGLSurface egl_surface = eglCreatePlatformWindowSurfaceEXT(egl_dpy, config, (void*) xlib_win, NULL); Example Code for Wayland - // The internal representation of the egl_dpy, created below, remembers that // it was derived from a Wayland display. struct wl_display *wl_dpy = wl_display_connect(NULL); EGLDisplay *egl_dpy = eglGetPlatformDisplay(EGL_PLATFORM_WAYLAND, wl_dpy); EGLConfig config; eglChooseConfig(egl_dpy, config, ...); // Since egl_dpy remembers that it was derived from an Wayland display, when // creating the EGLSurface below libEGL internally casts the // `(void*) wl_win` to `struct wl_egl_window*`. struct wl_egl_window *wl_win = wl_egl_window_create(...); EGLSurface egl_surface = eglCreateWindowSurface(egl_dpy, config, (void*) wl_win, NULL); Hi, is it possible to build a binary, that will use this extension if it is present in whatever libEGL is available at runtime, and if it is not, fall back gracefully to using the core eglGetDisplay()? Or is this specifically not supported, since I cannot see a way for runtime detection of this extension? Or is the runtime detection left unspecified, so one could do it with e.g. getting eglGetPlatformDisplay via dlsym()? Just a question that popped in my mind, since there were no comments toward that topic. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
