Re: [Mesa3d-dev] Galuim3d alteration idea. Cache and common storage for glsl to native gpu conversions .
On Sat, Mar 13, 2010 at 3:13 AM, Peter Dolding oia...@gmail.com wrote: http://ccache.samba.org/ is where part of this idea comes from. Speeding up glsl conversion to gpu code will make things more effective. There is no point running the glsl to native gpu conversions more times than that are require particularly on devices or anything that is depending on battery life. This brings me to the second half of the idea common storage framework. Directory struct that comes to mind for me. /usr/shared/galuim3d/target/application name/shader/version as filename Target would contain glsl for like the raw glsl and like R300 for card particular implementations as per a list. Of course version of compiler would have to be stuck at the start of the pre built GPU code and checked on load. If out of date rebuild. Then like a opengl extension to request shared glsl code access. galuim3dloader(application,shader,version) direct. galuim3dloaderlatest(application,shader) just to load the newest version of that shader. Few advantages of common glsl storage applications able to share glsl code like they can share libraries making it simple to implement fancy features on the gpu. Able to reduce how much glsl code has to be built to particular cards. And the possibility of allowing applications to migrate from card to card of different types without issues. Reason shader information commonally exposed. Same kind of caching for opencl would also be good. No point wasting cpu/gpu time running compilers when we can cache or store the results. Of course these ideas really were not possible to implement without access to raw GPU native code. Already done, at least the parts that make sense. We have a system called CSO (Constant State Objects) that caches native shader objects. We don't store them as files for a handful of reasons; the largest reason is that shaders need to be recompiled depending on other state inside the driver. -- Corbin Simpson mostawesomed...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.
Chia-I,
This looks like it introduces an extra full-window copying operation
at every swapbuffers... is that correct?
If so, I think we should try to figure out an alternative approach
without the copying... would actually flipping between two textures
(thus preserving the old back/new front) contents be workable?
Keith
On Sun, Mar 14, 2010 at 5:17 AM, Chia-I Wu o...@kemper.freedesktop.org wrote:
Module: Mesa
Branch: gallium-st-api
Commit: d6262bdcfb64e1f88f6a890829f5c30c26bc372b
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d6262bdcfb64e1f88f6a890829f5c30c26bc372b
Author: Chia-I Wu o...@lunarg.com
Date: Sun Mar 14 12:01:27 2010 +0800
st/glx: Sync the back buffer to the front buffer.
Consider this rendering sequence
* render to the back buffer
* swap buffers
* read from the front buffer
The front buffer is expected to have the contents of the back buffer.
---
src/gallium/state_trackers/glx/xlib/xm_st.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_st.c
b/src/gallium/state_trackers/glx/xlib/xm_st.c
index de5a35e..bcb8285 100644
--- a/src/gallium/state_trackers/glx/xlib/xm_st.c
+++ b/src/gallium/state_trackers/glx/xlib/xm_st.c
@@ -197,18 +197,36 @@ xmesa_st_framebuffer_validate(struct
st_framebuffer_iface *stfbi,
struct pipe_texture **out)
{
struct xmesa_st_framebuffer *xstfb = xmesa_st_framebuffer(stfbi);
- unsigned statt_mask, i;
+ unsigned statt_mask, new_mask, i;
+ boolean resized;
statt_mask = 0x0;
for (i = 0; i count; i++)
statt_mask |= 1 statts[i];
+ /* record newly allocated textures */
+ new_mask = statt_mask ~xstfb-texture_mask;
+
+ resized = (xstfb-buffer-width != xstfb-texture_width ||
+ xstfb-buffer-height != xstfb-texture_height);
/* revalidate textures */
- if (xstfb-buffer-width != xstfb-texture_width ||
- xstfb-buffer-height != xstfb-texture_height ||
- (xstfb-texture_mask statt_mask) != statt_mask) {
+ if (resized || new_mask) {
xmesa_st_framebuffer_validate_textures(stfbi,
xstfb-buffer-width, xstfb-buffer-height, statt_mask);
+
+ if (!resized) {
+ enum st_attachment_type back, front;
+
+ back = ST_ATTACHMENT_BACK_LEFT;
+ front = ST_ATTACHMENT_FRONT_LEFT;
+ /* copy the contents if front is newly allocated and back is not */
+ if ((statt_mask (1 back))
+ (new_mask (1 front))
+ !(new_mask (1 back))) {
+ xmesa_st_framebuffer_copy_textures(stfbi, back, front,
+ 0, 0, xstfb-texture_width, xstfb-texture_height);
+ }
+ }
}
for (i = 0; i count; i++) {
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] plumbing for gallium swrast_dri.so
Hi, I put some patches at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do the plumbing in order to build the swrast_dri wrapper around gallium instead of classic mesa. For reference, swrast_dri is the fallback driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It must not link with libdrm, nor use any drm headers during building because it is also used on platforms without drm. The branch is to the point where glxinfo runs and needs some glue with __DRIswrastLoaderExtension in order to show something other than black windows. The problem is that there seems to be two places where to put the glue, either in st/.../dri_drawable.c or in ws/.../swrast_drm_api.c . Can someone more familiar with gallium take a look at the branch and provide hints ? thanks, George. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.
On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell
keith.whitw...@googlemail.com wrote:
This looks like it introduces an extra full-window copying operation
at every swapbuffers... is that correct?
If so, I think we should try to figure out an alternative approach
without the copying... would actually flipping between two textures
(thus preserving the old back/new front) contents be workable?
Buffers swapping is handled in xmesa_swap_st_framebuffer. It is a zero-copy
operation.
This commit is to fix a bug when this code path is hit
/* draw something and ... */
glXSwapBuffers();
glReadBuffer(GL_FRONT);
glReadPixels();
In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be
added on demand as can be seen in st_ReadBuffer. The validation list would
become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }. When
glReadPixels is called, st/mesa will validate with the list and read from the
front buffer.
On the st/glx side, this use pattern is catched. When the front buffer is
allocated, the contents of the back buffer will be copied to the front buffer.
This happens only once. When the same code is run again, glXSwapBuffers will
swap the buffers.
The copying is required because xmesa_swap_st_framebuffer does not always swap
the buffers. It is so that only the back buffer is allocated when the
application never draws/reads the front buffer.
--
o...@lunarg.com
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.
On Sun, Mar 14, 2010 at 10:28 AM, Chia-I Wu olva...@gmail.com wrote:
On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell
keith.whitw...@googlemail.com wrote:
This looks like it introduces an extra full-window copying operation
at every swapbuffers... is that correct?
If so, I think we should try to figure out an alternative approach
without the copying... would actually flipping between two textures
(thus preserving the old back/new front) contents be workable?
Buffers swapping is handled in xmesa_swap_st_framebuffer. It is a zero-copy
operation.
This commit is to fix a bug when this code path is hit
/* draw something and ... */
glXSwapBuffers();
glReadBuffer(GL_FRONT);
glReadPixels();
In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be
added on demand as can be seen in st_ReadBuffer. The validation list would
become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }. When
glReadPixels is called, st/mesa will validate with the list and read from the
front buffer.
On the st/glx side, this use pattern is catched. When the front buffer is
allocated, the contents of the back buffer will be copied to the front buffer.
This happens only once. When the same code is run again, glXSwapBuffers will
swap the buffers.
The copying is required because xmesa_swap_st_framebuffer does not always swap
the buffers. It is so that only the back buffer is allocated when the
application never draws/reads the front buffer.
--
o...@lunarg.com
OK, sorry for being slow thanks for explaining...
Keith
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification
Hi guys, I came across this post and downloaded luca's version of Mesa (mesa-lb) using: git clone git://repo.or.cz/mesa/mesa-lb.git and then git checkout --track -b unification+fixes+stable origin/unification+fixes+stable and switched to that branch. I then for safety,I compiled and installed with: ./configure --prefix=/usr/local --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 --enable-debug http://old.nabble.com/file/p27895301/glxinfo-error.txt glxinfo-error.txt There were no compilation problems when I compiled Luca's version of Mesa.I re-booted into my root account.I fired up Konsole and ran glxinfo for the packaged version of Mesa for Fedora Rawhide,and that showed up fine.To see Luca'a version,I used : export LIBGL_DRIVERS_PATH=/usr/local/lib/dri and then glxinfo.I found a strange error near the top: Mesa: CPU name: AMD Athlon(tm) XP 3000+ Mesa warning: failed to remap index 390 Mesa warning: failed to remap index 391 Mesa warning: failed to remap index 392 Mesa warning: failed to remap index 398 Mesa warning: failed to remap index 399 I've attached a txt file with the full output.My graphics card is an Nvidia NV40 (6,600 GT),and I also compile DRM the nouveau kernel modules and the nouveau driver from git I wanted to merge Lucsa' branch in to my copy of Mesa master to test it out,but it would let me for some reason,any advice on that? Regards, STEVE555 Keith Whitwell-4 wrote: Sounds good to me - fewer driver directories to fix up after changes... Keith On Sat, Mar 13, 2010 at 5:29 PM, Luca Barbieri l...@luca-barbieri.com wrote: Currently the nv30 and nv40 Gallium drivers are very similar, and contain about 5000 lines of essentially duplicate code. I prepared a patchset (which can be found at http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) which gradually unifies the drivers, one file per the commit. A new nvfx directory is created, and unified files are put there one by one. After all patches are applied, the nv30 and nv40 directories are removed and the only the new nvfx directory remains. The first patches unify the engine naming (s/curie/eng3d/g; s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. Initial versions of this work changed renouveau.xml to create a new NVFXTCL object, but the current version doesn't need any renouveau.xml modification at all. The unification+fixes branch referenced above is the one that should be tested. The unification branch contains just the unification, with no behavior changes, while unification+fixes also fixes swtnl and quad rendering, allowing to better test the unification. Some cleanups on top of the unfication are also included. That same repository also contains other branches with significant improvements on top of the unification, but I'm still not proposing them for inclusion as they need more testing and some fixes. While there are some branches in the Mesa repository that would conflict with this, such branches seem to be popping up continuously (and this is good!), so waiting until they are merged probably won't really work. The conflicts are minimal anyway and the driver fixes can be very easily reconstructed over the unified codebase. How about merging this? Any objections? Any comments? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- View this message in context: http://old.nabble.com/-PATCH--nv30-nv40-Gallium-drivers-unification-tp27889377p27895301.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- Download Intel#174; Parallel Studio Eval Try the
[Mesa3d-dev] [Bug 27065] build failure: No rule to make target `../../../../src/gallium/drivers/softpipe/sp_winsys.h', needed by `x11/native_ximage.o'.
http://bugs.freedesktop.org/show_bug.cgi?id=27065 --- Comment #2 from David Ronis david.ro...@mcgill.ca 2010-03-14 09:50:58 PST --- Actually, I had run make clean and that didn't help; however, explicitly removing the depend file as you suggested seems to have worked. Thanks -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] i965 shader regression [bisected]
On Sat, 2010-03-13 at 16:52 +0200, Maxim Levitsky wrote: This time I caught it early. 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a is first bad commit commit 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a Author: Eric Anholt e...@anholt.net Date: Wed Mar 10 17:38:33 2010 -0800 i965: Do FS SLT, SGT, and friends using CMP, SEL instead of CMP, MOV, MOV. :04 04 d6abcec74652e20faf81feac8486cfb8ef979494 d5b5c11b472e463525965d9673c0170b0eb206f1 Msrc (Revert helps restore correct behaviour) This breaks several shaders in my examples folder, that I downloaded from GLSL tutorial site. (http://www.lighthouse3d.com/opengl/glsl/) Attached two example shaders. Best regards, Maxim Levitsky Ping -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Compiler warnings when building Mesa
Hi, here is a list with compiler warnings I have seen for a longer time. Just for info: libdrm: 20100313 XServer: 1.7.5 protos/macros: 20100311 I can also provide a full log (~1.4 MiB). Please decide whether fixing them is necessary/worth ... Thanks. Johannes gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -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_XEXTPROTO_71 shader/nvprogram.c -o shader/nvprogram.o lex.yy.c:3320: warning: no previous prototype for 'yyget_column' lex.yy.c:3396: warning: no previous prototype for 'yyset_column' lex.yy.c:2795: warning: 'yyunput' defined but not usedgcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -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_XEXTPROTO_71 shader/nvvertparse.c -o shader/nvvertparse.o lex.yy.c:2837: warning: 'input' defined but not used - gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -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_XEXTPROTO_71 swrast/s_accum.c -o swrast/s_accum.o swrast/s_aatriangle.c:277: warning: 'compute_coveragei' defined but not used - gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm-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_XEXTPROTO_71 r128_texmem.c -o r128_texmem.o In file included from r128_span.c:203: ../../../../../src/mesa/drivers/dri/common/depthtmp.h: In function 'r128WriteDepthSpan_z16': ../../../../../src/mesa/drivers/dri/common/depthtmp.h:45: warning: passing argument 5 of 'r128WriteDepthSpanLocked' from incompatible pointer type r128_ioctl.h:75: note: expected 'const GLuint *' but argument is of type 'const GLushort *' ../../../../../src/mesa/drivers/dri/common/depthtmp.h: In function 'r128WriteDepthPixels_z16': ../../../../../src/mesa/drivers/dri/common/depthtmp.h:146: warning: passing argument 5 of 'r128WriteDepthPixelsLocked' from incompatible pointer type r128_ioctl.h:79: note: expected 'const GLuint *' but argument is of type 'const GLushort *' - gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/drm-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_XEXTPROTO_71 -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm -DRADEON_R600 r700_vertprog.c -o r700_vertprog.o r700_assembler.c: In function 'callPreSub': r700_assembler.c:6157: warning: assignment from incompatible pointer type r700_assembler.c:6277: warning: assignment from incompatible pointer type - gcc -c -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_XEXTPROTO_71 -include main/mfeatures_es1.h -D__GL_EXPORTS -I. -I./glapi/glapi-es1 -I./state_tracker -I../state_tracker -I../../../include -I../../../src/mesa -I../../../src/gallium/include -I../../../src/gallium/auxiliary -o objs-es1/shader/nvfragparse.o ../shader/nvfragparse.c lex.yy.c:3320: warning: no previous prototype for 'yyget_column' lex.yy.c:3396: warning: no previous prototype for 'yyset_column' lex.yy.c:2795: warning: 'yyunput' defined but not used lex.yy.c:2837: warning: 'input'
Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification
Perhaps try running make clean and make if you haven't already? And perhaps make sure that the installed libGL.so and DRI drivers are build from the same codebase. The changes in my branch definitely shouldn't affect this. I wanted to merge Lucsa' branch in to my copy of Mesa master to test it out,but it would let me for some reason,any advice on that? What reason? git merge should work. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Compiler warnings when building Mesa
From: Johannes Obermayr johannesoberm...@gmx.de To: mesa3d-dev mesa3d-dev@lists.sourceforge.net Sent: Sun, March 14, 2010 1:30:27 PM Subject: [Mesa3d-dev] Compiler warnings when building Mesa Hi, here is a list with compiler warnings I have seen for a longer time. Just for info: libdrm: 20100313 XServer: 1.7.5 protos/macros: 20100311 I can also provide a full log (~1.4 MiB). Please decide whether fixing them is necessary/worth ... Thanks. Johannes I sent patches for some of the warnings I found recently. Most were accepted, and one is still under review (for the dri2_glx.c warnings). Most of the warnings are related to pointer casting, or unreferenced code. But one of the remaining warnings appears to point to a real issue: ... brw_vs_emit.c: In function 'brw_vs_emit': brw_vs_emit.c:1156: warning: array subscript is above array bounds ... c-regs is declared [TGSI_FILE_COUNT][128] , where TGSI_FILE_COUNT = 11 but this line tries to reference c-regs[TGSI_FILE_OUTPUT][VERT_RESULT_PSIZ] , where TGSI_FILE_OUTPUT = 3 and VERT_RESULT_PSIZ is #defined as 1 ! -- Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] master: undef/unmangled EGL functions are part of libOSMesa
From a build of master (41eab95b3bc29a4fe6fd08b7f1f80cef5bdc097f) [1]:
$ lib nm libOSMesa.so | grep EGL
00064254 t _mesa_EGLImageTargetRenderbufferStorageOES
000b30c0 t _mesa_EGLImageTargetTexture2DOES
U glEGLImageTargetRenderbufferStorageOES
U glEGLImageTargetTexture2DOES
0029bb70 T mglEGLImageTargetRenderbufferStorageOES
0029bb90 T mglEGLImageTargetTexture2DOES
this prevents using libOSMesa, since one gets link errors about the
symbol.
Similar output for libMesaGL.
I shouldn't get any EGL when using --disable-egl, right?. Maybe this
is just the luxury edition...
Side note: libGLU is linked against libOSMesa, so there are issues
using that in a mangled setting as well. Seems strange that GLU would
need OSMesa symbols, but I'll admit to not keeping up with devel
lately.
-tom
[1]
./configure \
CFLAGS=-g -DUSE_MGL_NAMESPACE \
CXXFLAGS=-g -DUSE_MGL_NAMESPACE \
--prefix=${PF}\
--without-demos \
--with-driver=osmesa \
--disable-gallium \
--disable-egl \
--with-max-width=16384\
--with-max-height=16384 \
--enable-glx-tls || exit 1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] undefined symbols and silent fallback to swrast
14:47 lb1 the fact is that if you remove a function from mesa .c file, everything will succeed, but the resulting driver will fail to load 14:47 lb1 because it cannot resolve that symbol 14:48 lb1 not sure why 14:48 lb1 I suppose even for shared libraries gcc/ld should fail on undefined symbols 14:48 lb1 maybe the makefiles disable that checking Can anyone shed any light on this, why the driver always succeeds to build and link even in the case of undefined symbols ? The second question is why the dlopen errors are not visible by default and require LIBGL_DEBUG=verbose to be displayed. It does not make sense to always print these errors by default ? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification
On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Sounds good to me - fewer driver directories to fix up after changes... It'd be good to get this merged sooner rather than later as I'll soon be starting on pipe_resources conversion for the nv drivers. Once I do that, there will be heaps of conflicts with your patches, but if I can merge them in before I do the conversion all will be well... Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification
On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Sounds good to me - fewer driver directories to fix up after changes... It'd be good to get this merged sooner rather than later as I'll soon be starting on pipe_resources conversion for the nv drivers. Once I do that, there will be heaps of conflicts with your patches, but if I can merge them in before I do the conversion all will be well... I tested unification+fixes branch on nv35 with 11 games that you can see on that page : http://nouveau.freedesktop.org/wiki/XavierChantry No regression to report compared to mesa master. A benefit worth mentioning is the SWTNL support which allows to run the 4 games currently broken with mesa master. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast
Xavier Chantry chantry.xav...@gmail.com writes: 14:47 lb1 the fact is that if you remove a function from mesa .c file, everything will succeed, but the resulting driver will fail to l oad 14:47 lb1 because it cannot resolve that symbol 14:48 lb1 not sure why 14:48 lb1 I suppose even for shared libraries gcc/ld should fail on undefined symbols 14:48 lb1 maybe the makefiles disable that checking Can anyone shed any light on this, why the driver always succeeds to build and link even in the case of undefined symbols ? That's just the default compiler/linker setup on Linux. This is in contrast to, say, OS X, where undefined symbols cause link errors. You can emulate the above by building with -Wl,--no-undefined (or maybe -no-undefined, something like that, see ld(1)). The second question is why the dlopen errors are not visible by default and require LIBGL_DEBUG=verbose to be displayed. It does not make sense to always print these errors by default ? Doesn't effect me personally, but errors coming up on stderr does seem like reasonable default behavior to me. Is it actually the case that these are always errors though (i.e. if a dlopen fails, does a higher level try loading a different driver which might succeed?)? -tom -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification
Dear Luca, I got your latest commits for your branch,did a make clean instead of make -B realclean as I usaully do and did an autoreconf -iv,then .autogen.sh with my configure options I mentioned earlier to ths thread.I then ran make and make install instead of gmake and gmake install,and rebooted. When I did export LIBGL_DRIVERS_PATH=/usr/local/lib/dri(then return) and ran glxinfo again,the error message appeared again.I then did a ldd /usr/bin/glxinfo in terminal I exported on and it was showing that it was pointing to libGL.so in /usr/lib. So I exported LD_LIBRARY_PATH=/usr/local/lib in the same Konsole window and ran glxinfo again.This time,the errors disappeared.I like to thank you for your advice. Regards, STEVE555 Xavier Chantry-3 wrote: On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Sounds good to me - fewer driver directories to fix up after changes... It'd be good to get this merged sooner rather than later as I'll soon be starting on pipe_resources conversion for the nv drivers. Once I do that, there will be heaps of conflicts with your patches, but if I can merge them in before I do the conversion all will be well... I tested unification+fixes branch on nv35 with 11 games that you can see on that page : http://nouveau.freedesktop.org/wiki/XavierChantry No regression to report compared to mesa master. A benefit worth mentioning is the SWTNL support which allows to run the 4 games currently broken with mesa master. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- View this message in context: http://old.nabble.com/-PATCH--nv30-nv40-Gallium-drivers-unification-tp27889377p27899191.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast
On Mon, Mar 15, 2010 at 12:41 AM, tom fogal tfo...@alumni.unh.edu wrote: That's just the default compiler/linker setup on Linux. This is in contrast to, say, OS X, where undefined symbols cause link errors. You can emulate the above by building with -Wl,--no-undefined (or maybe -no-undefined, something like that, see ld(1)). Looks like I am entering in a dangerous territory. With -Wl,--no-undefined, I get so many errors that it did not fit in my terminal buffer :P http://paste.pocoo.org/show/189694/ With -Wl,--no-allow-shlib-undefined it's a bit better but it is still scary : /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \ ../../common/driverfuncs.o ../common/utils.o swrast.o swrast_span.o ../../../../../src/mesa/libmesa.a-ldrm -lexpat -lm -lpthread -ldl mklib: Making Linux shared library: swrast_dri.so LDFLAGS : -Wl,--no-allow-shlib-undefined /lib/libpthread.so.0: undefined reference to `_dl_allocate_...@glibc_private' /lib/libpthread.so.0: undefined reference to `_dl_get_tls_static_i...@glibc_private' /lib/libc.so.6: undefined reference to `_dl_a...@glibc_private' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdl.so: undefined reference to `_rtld_global...@glibc_private' /lib/libpthread.so.0: undefined reference to `__tls_get_a...@glibc_2.3' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdrm.so: undefined reference to `clock_gett...@glibc_2.2.5' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdl.so: undefined reference to `_dl_rtld_di_seri...@glibc_private' /lib/libpthread.so.0: undefined reference to `_dl_make_stack_executa...@glibc_private' /lib/libpthread.so.0: undefined reference to `_dl_allocate_tls_i...@glibc_private' /lib/libpthread.so.0: undefined reference to `_rtld_glo...@glibc_private' /lib/libpthread.so.0: undefined reference to `__libc_stack_...@glibc_2.2.5' /lib/libc.so.6: undefined reference to `__libc_enable_sec...@glibc_private' /lib/libpthread.so.0: undefined reference to `_dl_deallocate_...@glibc_private' collect2: ld returned 1 exit status This is with swrast, but the result with nouveau was quite similar. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast
Xavier Chantry chantry.xav...@gmail.com writes: On Mon, Mar 15, 2010 at 12:41 AM, tom fogal tfo...@alumni.unh.edu wrote: You can emulate the [undefined link errors] by building with -Wl,--no-undefined (or maybe -no-undefined, something like that, see ld(1)). With -Wl,--no-undefined, I get so many errors that it did not fit in my terminal buffer :P With -Wl,--no-allow-shlib-undefined it's a bit better but it is still scary : Oops, sorry; I was thinking of that flag, but I forgot about the shlib variant expected --no-undefined to do --no-allow-shlib-undefined. Anyway, mea culpa, glad you figured out what I meant not what I said ;) /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \ ../../common/driverfuncs.o ../common/utils.o swrast.o swrast_sp an.o ../../../../../src/mesa/libmesa.a-ldrm -lexpat -lm -lpthread -ldl mklib: Making Linux shared library: swrast_dri.so LDFLAGS : -Wl,--no-allow-shlib-undefined /lib/libpthread.so.0: undefined reference to `_dl_allocate_...@glibc_private' /lib/libpthread.so.0: undefined reference to `_dl_get_tls_static_i...@glibc_private' These look like TLS issues. Did you provide --enable-glx-tls to configure? Looks like you probably want to, for your platform. -tom -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCHes] RFC: detect TLS during configuration
It was a long while back that I wondered somehow ended up
volunteering to detect platform TLS support, + enable it in Mesa / the
X server if available.
I got distracted before finishing the X parts, but rebased the Mesa
parts, which are attached.
One thing I'm worried about is using an AC macro archive macro here;
it's GPL + an exception that configure (the output) is unrestricted.
I'm not sure that'll be kosher for Mesa.
OTOH, the macro is dead simple.
Comments?
-tom
From eec65ace078b2b66e76ba79e9f67fa72d386 Mon Sep 17 00:00:00 2001
From: Tom Fogal tfo...@alumni.unh.edu
Date: Fri, 13 Nov 2009 21:19:18 -0700
Subject: [PATCH 1/2] RFC: Add macro to test for TLS from the AC macro archive.
This adds a macro to check for platform support of thread local
storage (TLS).
Note that the macro is under the GPL, meaning that this would
place Mesa's autoconf-based build system under the GPL as well.
The macro is placed in a separate file and included via
acinclude.m4. This methodology allows for easy upgrades should
the macro ever be modified upstream. The alternative is to place
the macro inline within acinclude.m4.
---
acinclude.m4 |2 +
ax_tls.m4| 74 ++
2 files changed, 76 insertions(+), 0 deletions(-)
create mode 100644 ax_tls.m4
diff --git a/acinclude.m4 b/acinclude.m4
index a5b389d..da6620d 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -117,3 +117,5 @@ if test $enable_pic != no; then
fi
AC_SUBST([PIC_FLAGS])
])# MESA_PIC_FLAGS
+
+m4_sinclude([ax_tls.m4])
diff --git a/ax_tls.m4 b/ax_tls.m4
new file mode 100644
index 000..7aa3383
--- /dev/null
+++ b/ax_tls.m4
@@ -0,0 +1,74 @@
+# ===
+# http://www.nongnu.org/autoconf-archive/ax_tls.html
+# ===
+#
+# SYNOPSIS
+#
+# AX_TLS
+#
+# DESCRIPTION
+#
+# Provides a test for the compiler support of thread local storage (TLS)
+# extensions. Defines TLS if it is found. Currently only knows about GCC
+# and MSVC. I think SunPro uses the same as GCC, and Borland apparently
+# supports either.
+#
+# LICENSE
+#
+# Copyright (c) 2008 Alan Woodland aj...@aber.ac.uk
+#
+# This program is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation, either version 3 of the License, or (at your
+# option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
+# Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program. If not, see http://www.gnu.org/licenses/.
+#
+# As a special exception, the respective Autoconf Macro's copyright owner
+# gives unlimited permission to copy, distribute and modify the configure
+# scripts that are the output of Autoconf when processing the Macro. You
+# need not follow the terms of the GNU General Public License when using
+# or distributing such scripts, even though portions of the text of the
+# Macro appear in them. The GNU General Public License (GPL) does govern
+# all other use of the material that constitutes the Autoconf Macro.
+#
+# This special exception to the GPL applies to versions of the Autoconf
+# Macro released by the Autoconf Archive. When you make and distribute a
+# modified version of the Autoconf Macro, you may extend this special
+# exception to the GPL to apply to your modified version as well.
+
+AC_DEFUN([AX_TLS], [
+ AC_MSG_CHECKING(for thread local storage (TLS) class)
+ AC_CACHE_VAL(ac_cv_tls, [
+ax_tls_keywords=__thread __declspec(thread) none
+for ax_tls_keyword in $ax_tls_keywords; do
+ case $ax_tls_keyword in
+ none) ac_cv_tls=none ; break ;;
+ *)
+ AC_TRY_COMPILE(
+[#include stdlib.h
+ static void
+ foo(void) {
+ static ] $ax_tls_keyword [ int bar;
+ exit(1);
+ }],
+ [],
+ [ac_cv_tls=$ax_tls_keyword ; break],
+ ac_cv_tls=none
+ )
+ esac
+done
+])
+
+ if test $ac_cv_tls != none; then
+dnl AC_DEFINE([TLS], [], [If the compiler supports a TLS storage class define it to that here])
+AC_DEFINE_UNQUOTED([TLS], $ac_cv_tls, [If the compiler supports a TLS storage class define it to that here])
+ fi
+ AC_MSG_RESULT($ac_cv_tls)
+])
--
1.7.0.2
From 5ccda10bd39bb89a3449bfabf2deb2dee54196bc Mon Sep 17 00:00:00 2001
From: Tom Fogal tfo...@alumni.unh.edu
Date: Fri, 13 Nov 2009 21:25:45 -0700
Subject: [PATCH 2/2] autoconf: Detect platform support for glX TLS.
Check for thread local
Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast
On Mon, Mar 15, 2010 at 1:18 AM, tom fogal tfo...@alumni.unh.edu wrote: Xavier Chantry chantry.xav...@gmail.com writes: /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \ ../../common/driverfuncs.o ../common/utils.o swrast.o swrast_sp an.o ../../../../../src/mesa/libmesa.a -ldrm -lexpat -lm -lpthread -ldl mklib: Making Linux shared library: swrast_dri.so LDFLAGS : -Wl,--no-allow-shlib-undefined /lib/libpthread.so.0: undefined reference to `_dl_allocate_...@glibc_private' /lib/libpthread.so.0: undefined reference to `_dl_get_tls_static_i...@glibc_private' These look like TLS issues. Did you provide --enable-glx-tls to configure? Looks like you probably want to, for your platform. I did have --enable-glx-tls I wonder if there are some problems with my system : $ readelf -s /lib/libpthread.so.0 | grep tls 3: 0 FUNCGLOBAL DEFAULT UND _dl_allocate_tls_i...@glibc_private (11) 29: 0 FUNCGLOBAL DEFAULT UND _dl_allocate_...@glibc_private (11) 30: 0 FUNCGLOBAL DEFAULT UND _dl_deallocate_...@glibc_private (11) 39: 0 FUNCGLOBAL DEFAULT UND __tls_get_a...@glibc_2.3 (15) 43: 0 FUNCGLOBAL DEFAULT UND _dl_get_tls_static_i...@glibc_private (11) 216: 0021b308 8 OBJECT LOCAL HIDDEN 29 __static_tls_align_m1 274: 6390 314 FUNCLOCAL HIDDEN 12 __pthread_init_static_tls 282: 00010e0412 OBJECT LOCAL DEFAULT 15 _thread_db_link_map_l_tls 396: 0021b320 8 OBJECT LOCAL HIDDEN 29 __static_tls_size 457: 0 FUNCGLOBAL DEFAULT UND _dl_allocate_tls_init@@GL 552: 0 FUNCGLOBAL DEFAULT UND _dl_allocate_tls@@GLIBC_P 555: 0 FUNCGLOBAL DEFAULT UND _dl_deallocate_tls@@GLIBC 587: 0 FUNCGLOBAL DEFAULT UND __tls_get_addr@@GLIBC_2.3 625: 0 FUNCGLOBAL DEFAULT UND _dl_get_tls_static_info@@ Assuming UND means undefined. This does not look too good. I am curious to know how it looks like on other systems. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Sapountzis wrote: Hi, I put some patches at http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do the plumbing in order to build the swrast_dri wrapper around gallium instead of classic mesa. For reference, swrast_dri is the fallback driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It must not link with libdrm, nor use any drm headers during building because it is also used on platforms without drm. The branch is to the point where glxinfo runs and needs some glue with __DRIswrastLoaderExtension in order to show something other than black windows. The problem is that there seems to be two places where to put the glue, either in st/.../dri_drawable.c or in ws/.../swrast_drm_api.c . Can someone more familiar with gallium take a look at the branch and provide hints ? If you're going to do this, please make a separate driver. Call it swrastg or something. I use swrast for testing new core Mesa features that I implement, and I don't want to be forced to muck about with Gallium to do that. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkudiSoACgkQX1gOwKyEAw8lTgCeIivQ/MSPks11BOP6I/JRrCGj rwEAnRkZ0ZYPUFsD3Bs1+qOXjWiTbXaM =T1u6 -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Correct GL_EQUIV code in r67/7xx.
From 247e121106e8d3e389f2e5a6edf13ea70ac18df7 Mon Sep 17 00:00:00 2001 These seem to be documented in http://www.svgopen.org/2003/papers/RasterOperationsUsingFilterElements/index.html. --- src/mesa/drivers/dri/r600/r700_state.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/r600/r700_state.c b/src/mesa/drivers/dri/r600/r700_state.c index 6f156b5..12eaebb 100644 --- a/src/mesa/drivers/dri/r600/r700_state.c +++ b/src/mesa/drivers/dri/r600/r700_state.c @@ -614,7 +614,7 @@ static GLuint translate_logicop(GLenum logicop) case GL_XOR: return 0x66; case GL_EQUIV: - return 0xaa; + return 0x99; case GL_AND_REVERSE: return 0x44; case GL_AND_INVERTED: -- 1.7.0 signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification
On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri l...@luca-barbieri.com wrote: Currently the nv30 and nv40 Gallium drivers are very similar, and contain about 5000 lines of essentially duplicate code. I prepared a patchset (which can be found at http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) which gradually unifies the drivers, one file per the commit. A new nvfx directory is created, and unified files are put there one by one. After all patches are applied, the nv30 and nv40 directories are removed and the only the new nvfx directory remains. The first patches unify the engine naming (s/curie/eng3d/g; s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. Initial versions of this work changed renouveau.xml to create a new NVFXTCL object, but the current version doesn't need any renouveau.xml modification at all. The unification+fixes branch referenced above is the one that should be tested. The unification branch contains just the unification, with no behavior changes, while unification+fixes also fixes swtnl and quad rendering, allowing to better test the unification. Some cleanups on top of the unfication are also included. That same repository also contains other branches with significant improvements on top of the unification, but I'm still not proposing them for inclusion as they need more testing and some fixes. While there are some branches in the Mesa repository that would conflict with this, such branches seem to be popping up continuously (and this is good!), so waiting until they are merged probably won't really work. The conflicts are minimal anyway and the driver fixes can be very easily reconstructed over the unified codebase. How about merging this? Any objections? Any comments? Pushed. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
