Re: [Mesa-dev] [RFC mesa-demos] Add --with-system-data-files configure option
2011/1/29 Henri Verbeet hverb...@gmail.com:
If you pass -M to format-patch, it becomes a lot smaller.
Thanks for the tip. For some reason I had to use -M -C --find-copies-harder.
Attached is the same patch, but with these options.
--
Paulo Zanoni
From df235322ecbe969ce70dcf516111686ff1d59ee0 Mon Sep 17 00:00:00 2001
From: Paulo Zanoni pzan...@mandriva.com
Date: Fri, 28 Jan 2011 17:34:24 -0200
Subject: [PATCH] Add --with-system-data-files option
If you specify --with-system-data-files, binaries will try to find .dat and
image files inside ${datadir}/${PACKAGE}. If you don't specify, they will try to
find the files inside ../data (keeping backwards compatibility).
Signed-off-by: Paulo Zanoni pzan...@mandriva.com
---
.gitignore |5 +++
CMakeLists.txt |2 +
Makefile.am |3 +-
configure.ac| 18 -
index.html |2 +-
m4/ac_define_dir.m4 | 49 +++
src/CMakeLists.txt |2 +-
src/Makefile.am |2 +-
src/{images = data}/CMakeLists.txt |2 +-
src/{images = data}/Makefile.am|9 +-
src/{images = data}/arch.rgb | Bin 793398 - 793398 bytes
src/{images = data}/bw.rgb | Bin 206452 - 206452 bytes
src/{demos = data}/geartrain.dat |0
src/{images = data}/girl.rgb | Bin 117075 - 117075 bytes
src/{images = data}/girl2.rgb | Bin 117139 - 117139 bytes
src/{demos = data}/isosurf.dat |0
src/{images = data}/reflect.rgb| Bin 39632 - 39632 bytes
src/{images = data}/s128.rgb | Bin 54258 - 54258 bytes
src/{demos = data}/terrain.dat |0
src/{images = data}/tile.rgb | Bin 206534 - 206534 bytes
src/{images = data}/tree2.rgba | Bin 66048 - 66048 bytes
src/{images = data}/tree3.rgb | Bin 24816 - 24816 bytes
src/{images = data}/wrs_logo.rgb | Bin 37574 - 37574 bytes
src/demos/CMakeLists.txt|4 ---
src/demos/Makefile.am |5 +---
src/demos/copypix.c |2 +-
src/demos/dissolve.c|4 +-
src/demos/drawpix.c |2 +-
src/demos/engine.c |2 +-
src/demos/fbo_firecube.c|7 +++--
src/demos/fire.c|7 +++--
src/demos/geartrain.c |2 +-
src/demos/gloss.c |4 +-
src/demos/ipers.c |2 +-
src/demos/isosurf.c |4 +-
src/demos/lodbias.c |2 +-
src/demos/multiarb.c|4 +-
src/demos/projtex.c |8 +++---
src/demos/rain.cxx |3 +-
src/demos/readpix.c |2 +-
src/demos/reflect.c |2 +-
src/demos/teapot.c |4 +-
src/demos/terrain.c |2 +-
src/demos/texcyl.c |2 +-
src/demos/textures.c|8 +++---
src/demos/tunnel.c |4 +-
src/demos/tunnel2.c |4 +-
src/demos/winpos.c |2 +-
src/fp/fp-tri.c |2 +-
src/fp/tri-tex.c|2 +-
src/fpglsl/fp-tri.c |2 +-
src/glsl/bump.c |2 +-
src/glsl/convolutions.c |2 +-
src/glsl/multitex.c |4 +-
src/glsl/texdemo1.c |2 +-
src/perf/glslstateschange.c |8 +++---
src/samples/sphere.c|2 +-
src/tests/afsmultiarb.c |4 +-
src/tests/arbfptexture.c|2 +-
src/tests/arbfptrig.c |2 +-
src/tests/arbnpot.c |2 +-
src/tests/arraytexture.c| 16 +-
src/tests/blendxor.c|2 +-
src/tests/bug_3195.c|2 +-
src/tests/bumpmap.c |2 +-
src/tests/ext422square.c|2 +-
src/tests/fillrate.c|4 +-
src/tests/floattex.c|2 +-
src/tests/fptexture.c |2 +-
src/tests/invert.c |2 +-
src/tests/mipmap_limits.c |2 +-
src/tests/mipmap_view.c |2 +-
src/tests/multipal.c|4 +-
src/tests/pbo.c |2 +-
src/tests/rubberband.c |2 +-
src/tests/texcmp.c |2 +-
src/tests/texcompress2.c|2 +-
src/tests/texline.c |2 +-
src/tests/texrect.c |4 +-
src/tests/vparray.c |2 +-
src/tests/yuvrect.c |2 +-
src/tests/yuvsquare.c |2 +-
src/xdemos/yuvrect_client.c |2 +-
83 files changed, 180 insertions(+), 106 deletions(-)
create mode 100644 m4/ac_define_dir.m4
rename src/{images =
[Mesa-dev] [Bug 33758] New: CreateDRIDrawable can't fail gracefully
https://bugs.freedesktop.org/show_bug.cgi?id=33758 Summary: CreateDRIDrawable can't fail gracefully Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: GLX AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: nob...@dreamwidth.org (I'm running on Ubuntu 10.04 x86-32 with mesa from the 7.10 Natty package, just for the record - but this bug is also in git and older versions.) In src/glx/glx_pbuffer.c, CreateDRIDrawable can fail, in which case it prints failed to create drawable, but the caller has no way of knowing that it failed at all and just keeps going. Whenever I called eglCreatePbuffer, failed to create drawable gets printed (not sure why - because Ubuntu 10.04 has a slightly older X server?), but I got a seemingly valid EGLSurface anyway. And when I tried to use it in eglMakeCurrent(), I get a mysterious segfault: Breakpoint 4, GLX_eglMakeCurrent (drv=0x80ec2e0, disp=0x80eb680, dsurf=0x8164370, rsurf=0x8164370, ctx=0x816ed10) at egl_glx.c:738 (gdb) next (...) 760 ret = GLX_drv-glXMakeCurrent(GLX_dpy-dpy, ddraw, cctx); (gdb) next Program received signal SIGSEGV, Segmentation fault. 0x00434e18 in ?? () from /usr/lib/mesa/libGL.so.1 (gdb) bt #0 0x00434e18 in ?? () from /usr/lib/mesa/libGL.so.1 #1 0x004356a7 in ?? () from /usr/lib/mesa/libGL.so.1 #2 0x004346f2 in ?? () from /usr/lib/mesa/libGL.so.1 #3 0x00412c3f in glXMakeCurrentReadSGI () from /usr/lib/mesa/libGL.so.1 #4 0x00412dd3 in glXMakeCurrent () from /usr/lib/mesa/libGL.so.1 #5 0x00462e8c in GLX_eglMakeCurrent (drv=0x80ec2e0, disp=0x80eb680, dsurf=0x8164370, rsurf=0x8164370, ctx=0x816ed10) at egl_glx.c:760 #6 0x00454f8f in eglMakeCurrent (dpy=0x80eb680, draw=0x8164370, read=0x8164370, ctx=0x816ed10) at eglapi.c:478 -- 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] Gallium proposal: add a user pointer in pipe_resource
On Sat, 2011-01-29 at 15:12 -0800, Marek Olšák wrote: Hi, I am proposing to add a pointer to a user buffer in pipe_resource. There are two reasons for this: 1) I would like to have a way to query outside of a driver whether a buffer is a user buffer. Simply comparing the pointer with NULL would do the trick. 2) I would like to efficiently obtain a pointer to a user buffer outside of a driver without going through the sequence of functions get_transfer, transfer_map, transfer_unmap, and transfer_destroy. This will allow to move more driver-specific code to auxiliary/util. Marek, I have to say my preference would have been to see user buffers fade away in favour of things like inline transfers. That said you're much more active than I am in looking at this right now, so I don't want to get in the way of your progress. I guess my biggest problem with user buffers is how poorly defined their semantics are. For instance, what does it really mean to get write transfer into a userbuffer? Will you be updating the original application-owned memory? And user-buffers tend not to stay user-buffers - they can be promoted to regular buffers behind the scenes by the driver. Would that be reflected in this interface somehow? From the point of view of recording, replaying, debugging, remoting, etc. at the gallium boundary, it's preferable if all actions are interposable - ie. all actions are mediated by a function call of some sort into the gallium interface. Giving a component a direct memory access into buffer contents would tend to defeat that and make record/replay of that action difficult. Is it possible to get a description of what you're doing at a slightly higher level to try and understand if there's a solution without these drawbacks? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33758] CreateDRIDrawable can't fail gracefully
https://bugs.freedesktop.org/show_bug.cgi?id=33758 --- Comment #1 from nobled nob...@dreamwidth.org 2011-01-31 06:26:26 PST --- It looks like the same problem is also in glxcmds.c:glXCreateGLXPixmap (it returns the same xid whether or not driScreen-createDrawable() returned null) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa trunk not compiling?
yes, i'm pretty sure i did that on the correct path and on top.
This problem was solved by one of the updates did by git pull, so now
i can compile mesa with no errors.
thanks!
On Sat, Jan 29, 2011 at 9:14 PM, Chia-I Wu olva...@gmail.com wrote:
On Fri, Jan 28, 2011 at 2:08 AM, Alberich de megres
alberich...@gmail.com wrote:
I did configure again, with the same error.
I'm using this configure line:
./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 \
--enable-gallium-nouveau --with-state-trackers=glx,dri,egl \
--with-egl-platforms=drm --enable-gles-overlay \
--enable-gallium-r600 --with-dri-drivers=i915,i965 \
--disable-gallium-{i915,i965}
At the end of the screen output, did you see nvc0 on the Driver
dirs: line? Did you execute make at the top directory of Mesa?
On Thu, Jan 27, 2011 at 6:49 PM, Lucas Stach d...@lynxeye.de wrote:
Just do ./configure again. After that it should compile just fine.
-- Lucas
Am Donnerstag, den 27.01.2011, 15:13 +0100 schrieb Alberich de megres:
Hi,
I'm trying to compile mesa trunk.
But i get this error:
gcc -c -o pipe_nouveau.o pipe_nouveau.c -I../../../../include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../src/gallium/include -I../../../../src/gallium/winsys
-I/usr/include/libdrm -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -g -O2 -Wall -Wmissing-prototypes
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV
gmake[3]: *** No rule for target
`../../../../src/gallium/drivers/nvc0/libnvc0.a', need for
`../../../../lib/egl/pipe_nouveau.so'. Stop..
gmake[3]: exiting from directory
`/root/Mesa/Mesa-git/mesa/src/gallium/targets/egl'
gmake[2]: *** [default] Error 1
gmake[2]:exiting from directory
`/root/Mesa/Mesa-git/mesa/src/gallium/targets'
make[1]: *** [subdirs] Error 1
make[1]: exiting from directory `/root/Mesa/Mesa-git/mesa/src'
make: *** [default] Error 1
Alberich
___
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
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] more EXT_framebuffer_sRGB, 965 support
On 01/27/2011 09:34 PM, Dave Airlie wrote: Okay looking for some review/comments, esp on the addition to the ctx-Const structure to denote if sRGB on FBOs is possible. Since just enabling the extension doesn't mean anything, we should probably enable it on anything that enables EXT_texture_sRGB. I'm not sure. What's the value in enabling an extension that doesn't do something useful? The extension spec says Implementations are encouraged to allow sRGB update and blending when rendering to sRGB textures using ARB_framebuffer_object but this is not required. I guess I'd rather implement what's suggested than just enabling a no-op extension. The patch looks fine. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glx: fix length of GLXGetFBConfigsSGIX
These patches look good to me. I'll commit soon. Thanks! -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
These look good, Henri. I'll commit them soon. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
On Sun, Jan 30, 2011 at 00:00:48 +0100, Henri Verbeet wrote: @@ -918,12 +921,15 @@ dri2CreateScreen(int screen, struct glx_display * priv) return psc-base; handle_error: + if (psc-fd) + close(psc-fd); 0 is a valid fd. It might be better to initialize fd to -1 and check for = 0 here. + if (psc-driver) + dlclose(psc-driver); Xfree(driverName); Xfree(deviceName); + glx_screen_cleanup(psc-base); XFree(psc); - /* FIXME: clean up here */ - return NULL; } Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
On 31 January 2011 17:43, Julien Cristau jcris...@debian.org wrote: On Sun, Jan 30, 2011 at 00:00:48 +0100, Henri Verbeet wrote: @@ -918,12 +921,15 @@ dri2CreateScreen(int screen, struct glx_display * priv) return psc-base; handle_error: + if (psc-fd) + close(psc-fd); 0 is a valid fd. It might be better to initialize fd to -1 and check for = 0 here. Yes, but isn't 0 defined to be stdin on any platform we care about? Though another reason to initialize to -1 would be that I just noticed we'd technically be passing an invalid fd to close() if the open failed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
The attached patch should do.
From ab34026885f98914efa6ad671f3446621124a55a Mon Sep 17 00:00:00 2001
From: Henri Verbeet hverb...@gmail.com
Date: Mon, 31 Jan 2011 18:09:19 +0100
Subject: [PATCH 1/1] glx: Properly check for a valid fd in dri2CreateScreen().
---
src/glx/dri2_glx.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index ab7915c..a275ba5 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -804,6 +804,8 @@ dri2CreateScreen(int screen, struct glx_display * priv)
return NULL;
memset(psc, 0, sizeof *psc);
+ psc-fd = -1;
+
if (!glx_screen_init(psc-base, screen, priv)) {
Xfree(psc);
return NULL;
@@ -921,7 +923,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
return psc-base;
handle_error:
- if (psc-fd)
+ if (psc-fd = 0)
close(psc-fd);
if (psc-driver)
dlclose(psc-driver);
--
1.7.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
On Mon, Jan 31, 2011 at 18:18:22 +0100, Henri Verbeet wrote: The attached patch should do. Looks good to me, thanks. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
On Mon, Jan 31, 2011 at 10:20 AM, Julien Cristau jcris...@debian.org wrote: On Mon, Jan 31, 2011 at 18:18:22 +0100, Henri Verbeet wrote: The attached patch should do. Looks good to me, thanks. Committed. Thanks, guys. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote: On 31.01.2011 19:46, Marek Olšák wrote: With this manager, the drivers don't have to deal with user buffers when they are bound as vertex buffers. They only get real hardware buffers. Please do *not* take away my user buffers and put user vertex arrays at the mercy of a state tracker ! In the DrawArrays case I usually use util/translate and interleave them letting it write directly into my command buffer for immediate mode vertex data submission. Christoph, Is there any reason for not wanting to the same optimization for non-user buffers? If the buffers are small and used only once, wouldn't you still want to write them directly into the command buffer? Because eliminating user buffers does not imply eliminating these optimization opportunities -- the driver can still know how big a buffer is, and the state tracker can set a flag such as PIPE_USAGE_ONCE to help the pipe driver figure out this is a fire and forget buffer. Perhaps we can have a PIPE_CAP for distinguishing the drivers that can inline small buffers, vs those who can and prefer them batched up in big vbos. And lets not forget the user arrays are a deprecated feature of GL. Applications will have to create a vbo even if all they wanna do is a draw a textured quad, therefore small vbos are worthwhile to optimize regardless. I'm not saying we must get rid of user buffers now, but I can't help feeling that it is odd that while recent versions of GL/DX APIs are eliminating index/vertex buffers in user memory, Gallium is optimizing for them... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
On Mon, Jan 31, 2011 at 9:17 PM, José Fonseca jfons...@vmware.com wrote: On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote: On 31.01.2011 19:46, Marek Olšák wrote: With this manager, the drivers don't have to deal with user buffers when they are bound as vertex buffers. They only get real hardware buffers. Please do *not* take away my user buffers and put user vertex arrays at the mercy of a state tracker ! In the DrawArrays case I usually use util/translate and interleave them letting it write directly into my command buffer for immediate mode vertex data submission. Christoph, Is there any reason for not wanting to the same optimization for non-user buffers? If the buffers are small and used only once, wouldn't you still want to write them directly into the command buffer? Because eliminating user buffers does not imply eliminating these optimization opportunities -- the driver can still know how big a buffer is, and the state tracker can set a flag such as PIPE_USAGE_ONCE to help the pipe driver figure out this is a fire and forget buffer. Perhaps we can have a PIPE_CAP for distinguishing the drivers that can inline small buffers, vs those who can and prefer them batched up in big vbos. And lets not forget the user arrays are a deprecated feature of GL. Applications will have to create a vbo even if all they wanna do is a draw a textured quad, therefore small vbos are worthwhile to optimize regardless. I'm not saying we must get rid of user buffers now, but I can't help feeling that it is odd that while recent versions of GL/DX APIs are eliminating index/vertex buffers in user memory, Gallium is optimizing for them... FWIW, the fact that something is deprecated in GL shouldn't concern us. Some deprecated features are only removed in the Core profile, which is very rarely used by developers. The GL4/Compatibility profile still contains everything, no features have been eliminated there. And we have to implement both the profiles, because people use both. The deprecation mechanism in OpenGL really doesn't make our lives easier at all. Whether user buffers should be exposed via the Gallium interface is an entirely different question though. I see my effort as moving towards eventually eliminating user buffers by simplifying the logic around them. The section 1) in my previous email is about eliminating any user-buffer-related code from drivers (though this step is optional). The section 2) talks about removing some user-buffer-specific code from st/mesa, optimizing things in the process. I can see nothing wrong with those. ;) Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
On 31.01.2011 21:17, José Fonseca wrote: On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote: On 31.01.2011 19:46, Marek Olšák wrote: With this manager, the drivers don't have to deal with user buffers when they are bound as vertex buffers. They only get real hardware buffers. Please do *not* take away my user buffers and put user vertex arrays at the mercy of a state tracker ! In the DrawArrays case I usually use util/translate and interleave them letting it write directly into my command buffer for immediate mode vertex data submission. Christoph, Is there any reason for not wanting to the same optimization for non-user buffers? For non-user buffers this is not an optimization. Immediate mode (sending vertices through the command buffer) bypasses the vertex cache, which is perfectly fine for user buffers which I cannot cache anyway since they might change at any time. Also, non-user buffers are already accessible by the GPU so VFETCH can go right ahead and do all the work. If the buffers are small and used only once, wouldn't you still want to write them directly into the command buffer? As I said, they're already in GPU accessible system memory or even VRAM, no reason to let the CPU move the data around before letting the GPU read it. Unless you're suggesting to do lazy transfers / real buffer allocations ? Because eliminating user buffers does not imply eliminating these optimization opportunities -- the driver can still know how big a buffer is, and the state tracker can set a flag such as PIPE_USAGE_ONCE to help the pipe driver figure out this is a fire and forget buffer. Perhaps we The case where user buffers + immediate mode are a real win right now is when the application asks you to pull e.g. vertices 0, 16, 25, and 8999 from the user memory. You do not know it will do that at transfer time, and if you write min index to max index to your scratch buffer, you copy around 8996 vertices too many instead of just extracting these 4 directly from the source and putting them into the command buffer. can have a PIPE_CAP for distinguishing the drivers that can inline small buffers, vs those who can and prefer them batched up in big vbos. And lets not forget the user arrays are a deprecated feature of GL. Applications will have to create a vbo even if all they wanna do is a draw a textured quad, therefore small vbos are worthwhile to optimize regardless. That's true, but doesn't automatically make all the old OpenGL applications use VBOs. I still want those to run as fast as possible. Gallium's task shouldn't be to patronize me wherever possible, even if it really enjoys doing that from time to time. I'm not saying we must get rid of user buffers now, but I can't help feeling that it is odd that while recent versions of GL/DX APIs are eliminating index/vertex buffers in user memory, Gallium is optimizing for them... Gallium is not. The pipe driver is optimizing the case where they are practical. Christoph. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32666] etqw triggers an assert in st_texture.c
https://bugs.freedesktop.org/show_bug.cgi?id=32666 Álmos aaalmo...@gmail.com changed: What|Removed |Added Component|Drivers/Gallium/r300|Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org --- Comment #1 from Álmos aaalmo...@gmail.com 2011-01-31 14:41:00 PST --- Since 1dd8e2757852682af44b63193c89dff3c09c7703 it asserts at a different position: at line 144 in st_gl_texture_dims_to_pipe_dims() in the GL_TEXTURE_CUBE_MAP branch of the switch conditional. Removing that assert (which seems pointless to me, because depthIn is not actually used in that case) restores the old behavior. -- 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 33786] New: Wayland terminal garbage starting with 1dd8e2757852682af44b63193c89dff3c09c7703
https://bugs.freedesktop.org/show_bug.cgi?id=33786 Summary: Wayland terminal garbage starting with 1dd8e2757852682af44b63193c89dff3c09c7703 Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: dar...@chaosreigns.com commit 1dd8e2757852682af44b63193c89dff3c09c7703 Author: Brian Paul bri...@vmware.com Date: Fri Jan 28 20:25:27 2011 -0700 st/mesa: fix texture array dimensions Wayland terminal output is garbage, and flips between two sets of garbage every time I click it, starting with this commit. Similar garbage when resizing terminal or dnd client. Comments from krh: it's probably the use of cairo_push_group that breaks somehow it could be a cairo-gl too, I think -- 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 33786] Wayland terminal garbage starting with 1dd8e2757852682af44b63193c89dff3c09c7703
https://bugs.freedesktop.org/show_bug.cgi?id=33786 Darxus dar...@chaosreigns.com changed: What|Removed |Added CC||dar...@chaosreigns.com -- 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 32666] etqw triggers an assert in st_texture.c
https://bugs.freedesktop.org/show_bug.cgi?id=32666 --- Comment #2 from Brian Paul bri...@vmware.com 2011-01-31 15:06:21 PST --- Can you provide a gdb stack trace at the assertion? -- 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 32666] etqw triggers an assert in st_texture.c
https://bugs.freedesktop.org/show_bug.cgi?id=32666 --- Comment #3 from Álmos aaalmo...@gmail.com 2011-01-31 15:24:22 PST --- Created an attachment (id=42784) -- (https://bugs.freedesktop.org/attachment.cgi?id=42784) gdb backtrace -- 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] Flex and bison generated files in revision control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tracking files generated by flex and bison puts an undue burden on people doing work on the various parers and lexers in Mesa. Tracking files generated by flex and bison generates extraneous noise in commit logs. Tracking files generated by flex and bison makes cherry-picking fixes from the development branch back to stable branches more difficult than it needs to be. Tracking files generated by flex and bison is a just plain bad idea. Flex and bison have working ports for every platform on which we support building Mesa. It even works when building projects from within Visual Studio (http://msdn.microsoft.com/en-us/library/aa730877%28vs.80%29.aspx). I have just pused a branch called flex-and-bison-required that removes these files. What still needs to be done in that branch: - Generate the files that have been removed during tarball creation. - Checks for flex and bison in configure.ac. - Fixes for your platform. If this branch does not work out-of-the-box on your platform, push fixes. On March 1st (or sooner with consensus) this branch will be merged to master. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1HSc4ACgkQX1gOwKyEAw8G5ACfarVmooeUeIeD42RDmJesfSmX Y2MAoJxeXryvDTrSsXDtd8KAdjT1xrrE =mEnX -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Flex and bison generated files in revision control
Sounds good. I've been planning to setup bison/flex on our build daemons for some time now, but other important stuff keeps popping up, but once this is done I wont be able to delay it further :) It can be it earlier as far as I'm concerned -- I think 7th Feb should give enough time. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Ian Romanick [i...@freedesktop.org] Sent: Monday, January 31, 2011 23:46 To: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] Flex and bison generated files in revision control -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tracking files generated by flex and bison puts an undue burden on people doing work on the various parers and lexers in Mesa. Tracking files generated by flex and bison generates extraneous noise in commit logs. Tracking files generated by flex and bison makes cherry-picking fixes from the development branch back to stable branches more difficult than it needs to be. Tracking files generated by flex and bison is a just plain bad idea. Flex and bison have working ports for every platform on which we support building Mesa. It even works when building projects from within Visual Studio (http://msdn.microsoft.com/en-us/library/aa730877%28vs.80%29.aspx). I have just pused a branch called flex-and-bison-required that removes these files. What still needs to be done in that branch: - Generate the files that have been removed during tarball creation. - Checks for flex and bison in configure.ac. - Fixes for your platform. If this branch does not work out-of-the-box on your platform, push fixes. On March 1st (or sooner with consensus) this branch will be merged to master. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1HSc4ACgkQX1gOwKyEAw8G5ACfarVmooeUeIeD42RDmJesfSmX Y2MAoJxeXryvDTrSsXDtd8KAdjT1xrrE =mEnX -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33758] CreateDRIDrawable can't fail gracefully
https://bugs.freedesktop.org/show_bug.cgi?id=33758 --- Comment #2 from nobled nob...@dreamwidth.org 2011-01-31 16:50:38 PST --- Okay, with debug symbols now the backtrace is: #0 0x00434e18 in XCreateDrawable (base=0x811caa0, xDrawable=102760449, drawable=102760449, modes=0x8170ff0) at drisw_glx.c:94 #1 driCreateDrawable (base=0x811caa0, xDrawable=102760449, drawable=102760449, modes=0x8170ff0) at drisw_glx.c:377 #2 0x004356a7 in driFetchDrawable (gc=0x8167468, glxDrawable=102760449) at dri_common.c:373 #3 0x004346f2 in drisw_bind_context (context=0x8167468, old=0x44a1c0, draw=102760449, read=102760449) at drisw_glx.c:266 #4 0x00412c3f in MakeContextCurrent (dpy=0x81400c0, draw=102760449, read=102760449, gc_user=0x8167468) at glxcurrent.c:263 #5 0x00412dd3 in glXMakeCurrent (dpy=0x81400c0, draw=102760449, gc=0x8167468) at glxcurrent.c:287 #6 0x00462e8c in GLX_eglMakeCurrent (drv=0x80ec2e0, disp=0x80eb680, dsurf=0x8164370, rsurf=0x8164370, ctx=0x816ed10) at egl_glx.c:760 #7 0x00454f8f in eglMakeCurrent (dpy=0x80eb680, draw=0x8164370, read=0x8164370, ctx=0x816ed10) at eglapi.c:478 XGetVisualInfo() returned null, and that doesn't get checked for. -- 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
