Re: [Mesa3d-dev] [RFC] gallium-targets merge
Hi I since this was not a interface change and I think I got a large enough test sample from various people I have merged the branch to master. I confirmed that the following builds are working; configure with all drivers, configure default, make linux-debug, scons with dri=yes, scons with dri=no. Cheers Jakob. -- 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] [Bug 27301] r300g: segfault while running glxgears
http://bugs.freedesktop.org/show_bug.cgi?id=27301 --- Comment #1 from Alex Deucher ag...@yahoo.com 2010-03-25 07:11:22 PST --- IGP cards don't currently work properly with r300g. -- 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] plumbing for gallium swrast_dri.so
I pushed this to master, swrastg_dri was added to the autoconf build system only. I also did a merge with gallium-resources for st/dri at ~gsap7/gallium-resources-merge-drisw, it basically reverts the old conversion, merges and redoes the conversion because there were a lot of conflicts, hope this is ok. regards, George. On Tue, Mar 23, 2010 at 6:52 PM, George Sapountzis gsapount...@gmail.com wrote: On Sun, Mar 14, 2010 at 12:25 PM, George Sapountzis gsapount...@gmail.com 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. I updated the patches with the feedback from the list and added TODO items at the top of drisw.c with the remaining issues. I think it's in good state, given the scope of swrastg_dri.so, and would like to merge this to master. So please review and test, esp. DRI2 and scons (since I cannot test DRI2 and have a tendency to break the build system ...) There is also the issue of when to choose swrastg_dri.so over swrast_dri.so that should be handled by the loaders, just rename swrastg_dri.so to swrast_dri.so for now. regards, 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
[Mesa3d-dev] [Bug 27301] r300g: segfault while running glxgears
http://bugs.freedesktop.org/show_bug.cgi?id=27301 Joakim Sindholt b...@zhasha.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Joakim Sindholt b...@zhasha.com 2010-03-25 08:29:53 PST --- *** This bug has been marked as a duplicate of bug 24942 *** -- 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
[Mesa3d-dev] [Bug 24942] r300g: R300 Gallium SW TCL
http://bugs.freedesktop.org/show_bug.cgi?id=24942 Joakim Sindholt b...@zhasha.com changed: What|Removed |Added CC||tstel...@gmail.com --- Comment #2 from Joakim Sindholt b...@zhasha.com 2010-03-25 08:29:53 PST --- *** Bug 27301 has been marked as a duplicate of this bug. *** -- 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] [RFC] gallium-targets merge
I've been using the configure line from nouveau wiki for a while now : http://nouveau.freedesktop.org/wiki/GalliumHowto ./configure --enable-debug --enable-glx-tls --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests Gallium: yes Gallium dirs:auxiliary drivers state_trackers Target dirs: dri-nouveau egl-nouveau dri-swrast egl-swrast Winsys dirs: sw sw/xlib sw/dri sw/drm nouveau/drm Driver dirs: softpipe failover trace identity nouveau nvfx nv50 Trackers dirs: glx dri Shared libs: yes Static libs: no EGL: glx dri2 GLU: yes GLw: yes (Motif: no) glut:yes Demos: no This setup broke after that last merge I think : make[3]: Entering directory `/home/xavier/app/mesa/src/gallium/targets/egl-nouveau' gcc -c -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o make[3]: *** No rule to make target `../../../../src/gallium/state_trackers/egl/libeglx11.a', needed by `egl_x11_nouveau.so'. Stop. It seems egl is enabled by default, but manually specifying state-trackers without egl disables egl state tracker, and build fails. I am not sure why it worked before. I don't know if configure.ac should handle the above configure line somehow, either reporting it as invalid or enabling egl state tracker anyway. On Thu, Mar 25, 2010 at 3:06 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Hi I since this was not a interface change and I think I got a large enough test sample from various people I have merged the branch to master. I confirmed that the following builds are working; configure with all drivers, configure default, make linux-debug, scons with dri=yes, scons with dri=no. Cheers Jakob. -- 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
Re: [Mesa3d-dev] [RFC] gallium-targets merge
On Thu, Mar 25, 2010 at 6:35 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Thanks for testing... Hmm I currently only checking for if the --enable-egl switch has been thrown when selecting so if you throw in --disable-egl in there it should work again. I'll look into it. Interestingly enough, the drisw work that happened right after the merge fails in the same way. Anyway, I already have two working options : 1) add egl and drisw to --with-state-trackers=glx,dri 2) add --disable-egl --enable-gallium-swrast=no The handling of with_state_trackers option does not seem optimal : - yes case : mesa_driver=dri - glx state tracker mesa_driver=xlib - dri state tracker so there is apparently no way to get both glx and dri - * case : does not check whether egl state tracker is enabled when egl is enabled does not check whether drisw state tracker is enabled when drisw is enabled But there is nothing inherently broken. So we can just assume the user is not stupid and will select configure options that are consistent. I will just go with 2), and possibly update nouveau wiki accordingly. -- 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] [RFC] gallium-targets merge
On Thu, Mar 25, 2010 at 7:06 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Thu, Mar 25, 2010 at 6:35 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Thanks for testing... Hmm I currently only checking for if the --enable-egl switch has been thrown when selecting so if you throw in --disable-egl in there it should work again. I'll look into it. Interestingly enough, the drisw work that happened right after the merge fails in the same way. Anyway, I already have two working options : 1) add egl and drisw to --with-state-trackers=glx,dri 2) add --disable-egl --enable-gallium-swrast=no The handling of with_state_trackers option does not seem optimal : - yes case : mesa_driver=dri - glx state tracker mesa_driver=xlib - dri state tracker so there is apparently no way to get both glx and dri - * case : does not check whether egl state tracker is enabled when egl is enabled does not check whether drisw state tracker is enabled when drisw is enabled But there is nothing inherently broken. So we can just assume the user is not stupid and will select configure options that are consistent. I will just go with 2), and possibly update nouveau wiki accordingly. Thanks again for testing. Okay, this could be solved by just checking if the state trackers are built where we enable the the targets instead of the subsystem or driver. The xorg drivers is the only one doing this correctly, by checking HAVE_XORG. I'll get to that later today. Cheers Jakob. -- 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
On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis gsapount...@gmail.com wrote: On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Mar 25, 2010 at 3:12 PM, George Sapountzis gsapount...@gmail.com wrote: I pushed this to master, swrastg_dri was added to the autoconf build system only. I also did a merge with gallium-resources for st/dri at ~gsap7/gallium-resources-merge-drisw, it basically reverts the old conversion, merges and redoes the conversion because there were a lot of conflicts, hope this is ok. Hi George, Let me first of say that despite my negative tone in the following text I do really like what you have done, thanks for figuring it out and doing the work. I really don't like the way you reuse the dri state tracker file to produce two different o file form the same c file. Magic defines on the build line that make the c file take different paths make the code harder to read and there is a big chance that some paths just bit rot. However to does seems to be very limited. And I also realize that the is no way around it due to the fact that you have to work against two different dri_util.h files and as such two different dri interfaces. I agree it's not pretty either. It's basically like having different CFLAGS for multiple .la's in automake. It's limited to init_screen, flush_front/swap_buffers/alloc_buffers which is exactly where the DRI versions are pretty different. Yeah its not as bad as it could be, and there really isn't any way around it with regard to that drisw_util.h vs dri_util.h. I have attached 4 patches that I like to run by you before pushing. 0001 is rather trivial and is just a code cleanup that adds dri2 prefix for functions that are in the dri2.c file. 0002 just removes the drisw.h from the drm build and dri[1|2].h from the sw build, just to be extra sure we don't use the wrong functions in the wrong place (you get a build time warning plus a link error, instead of just a link error). These look good. Cool I'll push those. 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet again for clarity. 0004 moves the common files into a common directory. I think that it may be better to just consolidate dri_screen.c / dri_context.c / dri_drawable.c / dri_extension.c in a single file named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib state_tracker. There is not much left in the above files after splitting out version-specific code. Then you will have: dri_api.c or dri_driver_api.c for the DRI window system binding dri_st_api.c and dri1.c dri2.c drisw.c for the different versions the only outlier is dri1_helper which I agree may have a better name. But then I looked at this a lot lately and your suggestion may be better for someone looking at it after some time. I think you can do both, the moving of the files is more for making it blatantly clear what is going on. The common files live in the common directory and the rest are in their own directory. This mirrors what is done in egl. I'm ambivalent about grouping the files together. And I don't think that moving them it a common directory stops us from doing either one. Then again dri_extension.c is quite useless, and should probably be moved into dri_screen either way. Are you strongly against the layout that I suggested? I have no real problem with doing both? One thing that could be done to reduce the amount of #ifdefs would be to move the tables from dri_screen.c into drisw.c and dri2.c. yes, this could be done unless the suggestion above is adopted, in which case I thinks it's probably better to keep all the dri_ functions static and the _DriverAPI tables in the common file. There is only one function that is static that is used in the tables, or are you meaning that we should make them static as we move all of them into a single file? And create a virtual function on the screen for flush_frontbuffer alloc_texture and so on. This vtbl already exists, it's the st_framebuffer_iface. However you implement this, I think you would end up with either an ifdef or having the same symbol in the different DRI version files, I don't know which is better. Ah yes double vtable, hmm, well anyways its not that invasive. Thanks for looking at the patches, No problems, thanks for looking at mine :) Cheers Jakob. -- 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] [RFC] Draw module patch and BGRA fix for i915g
Hi Brian, Keith, Zack et al.
So I tried to get i915g running again and it looks like there is a
RGBA vs BGRA bug in the draw module. I have attached two patches that
I would like to have some comments on before commit.
Patch 1 removes a bunch of switch cases that was strew all over the
draw module that all pretty much did exactly the same thing. Which
made it hard to fix the RGBA issue for i915g. In draw_pipe_vbuf and
draw_pt_emit the format for EMIT_4UB was one thing and in
draw_pt_fetch_emit it was another. In light of the format clean up I
standardized on following the same as the float formats for EMIT_4UB.
Patch 2 then introduces EMIT_4UB_BGRA and is used by i915g to make the
colors look correct again.
Comments please.
Cheers Jakob.
From 25fd65438993cf0b1e1f0846a9f94f970280cb32 Mon Sep 17 00:00:00 2001
From: Jakob Bornecrantz wallbra...@gmail.com
Date: Thu, 25 Mar 2010 00:18:30 +0100
Subject: [PATCH] draw: Use translate function instead of switch cases
---
src/gallium/auxiliary/draw/draw_pipe_vbuf.c| 37 +++--
src/gallium/auxiliary/draw/draw_pt_emit.c | 37 +++--
src/gallium/auxiliary/draw/draw_pt_fetch_emit.c| 42 +---
.../auxiliary/draw/draw_pt_fetch_shade_emit.c | 29 ++
src/gallium/auxiliary/draw/draw_vertex.c | 32 ---
src/gallium/auxiliary/draw/draw_vertex.h | 18
6 files changed, 53 insertions(+), 142 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_vbuf.c b/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
index 2709957..69e3304 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_vbuf.c
@@ -238,38 +238,15 @@ vbuf_start_prim( struct vbuf_stage *vbuf, uint prim )
unsigned output_format;
unsigned src_offset = (vbuf-vinfo-attrib[i].src_index * 4 * sizeof(float) );
- switch (vbuf-vinfo-attrib[i].emit) {
- case EMIT_4F:
- output_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
- emit_sz = 4 * sizeof(float);
- break;
- case EMIT_3F:
- output_format = PIPE_FORMAT_R32G32B32_FLOAT;
- emit_sz = 3 * sizeof(float);
- break;
- case EMIT_2F:
- output_format = PIPE_FORMAT_R32G32_FLOAT;
- emit_sz = 2 * sizeof(float);
- break;
- case EMIT_1F:
- output_format = PIPE_FORMAT_R32_FLOAT;
- emit_sz = 1 * sizeof(float);
- break;
- case EMIT_1F_PSIZE:
- output_format = PIPE_FORMAT_R32_FLOAT;
- emit_sz = 1 * sizeof(float);
+ output_format = draw_translate_vinfo_format(vbuf-vinfo-attrib[i].emit);
+ emit_sz = draw_translate_vinfo_format_size(vbuf-vinfo-attrib[i].emit);
+
+ /* doesn't handle EMIT_OMIT or unknown */
+ assert(emit_sz != 0);
+
+ if (vbuf-vinfo-attrib[i].emit == EMIT_1F_PSIZE) {
src_buffer = 1;
src_offset = 0;
- break;
- case EMIT_4UB:
- output_format = PIPE_FORMAT_A8R8G8B8_UNORM;
- emit_sz = 4 * sizeof(ubyte);
- break;
- default:
- assert(0);
- output_format = PIPE_FORMAT_NONE;
- emit_sz = 0;
- break;
}
hw_key.element[i].type = TRANSLATE_ELEMENT_NORMAL;
diff --git a/src/gallium/auxiliary/draw/draw_pt_emit.c b/src/gallium/auxiliary/draw/draw_pt_emit.c
index ae357b5..56fab1c 100644
--- a/src/gallium/auxiliary/draw/draw_pt_emit.c
+++ b/src/gallium/auxiliary/draw/draw_pt_emit.c
@@ -86,40 +86,15 @@ void draw_pt_emit_prepare( struct pt_emit *emit,
unsigned output_format;
unsigned src_offset = (vinfo-attrib[i].src_index * 4 * sizeof(float) );
+ output_format = draw_translate_vinfo_format(vinfo-attrib[i].emit);
+ emit_sz = draw_translate_vinfo_format_size(vinfo-attrib[i].emit);
-
- switch (vinfo-attrib[i].emit) {
- case EMIT_4F:
- output_format = PIPE_FORMAT_R32G32B32A32_FLOAT;
- emit_sz = 4 * sizeof(float);
- break;
- case EMIT_3F:
- output_format = PIPE_FORMAT_R32G32B32_FLOAT;
- emit_sz = 3 * sizeof(float);
- break;
- case EMIT_2F:
- output_format = PIPE_FORMAT_R32G32_FLOAT;
- emit_sz = 2 * sizeof(float);
- break;
- case EMIT_1F:
- output_format = PIPE_FORMAT_R32_FLOAT;
- emit_sz = 1 * sizeof(float);
- break;
- case EMIT_1F_PSIZE:
- output_format = PIPE_FORMAT_R32_FLOAT;
- emit_sz = 1 * sizeof(float);
+ /* doesn't handle EMIT_OMIT or unknown */
+ assert(emit_sz != 0);
+
+ if (vinfo-attrib[i].emit == EMIT_1F_PSIZE) {
src_buffer = 1;
src_offset = 0;
- break;
- case EMIT_4UB:
- output_format = PIPE_FORMAT_A8R8G8B8_UNORM;
- emit_sz = 4 * sizeof(ubyte);
- break;
- default:
- assert(0);
- output_format = PIPE_FORMAT_NONE;
- emit_sz = 0;
- break;
}
hw_key.element[i].type = TRANSLATE_ELEMENT_NORMAL;
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_emit.c b/src/gallium/auxiliary/draw/draw_pt_fetch_emit.c
index 2a60447..4c8086f 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_emit.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_emit.c
@@ -129,41 +129,19 @@
Re: [Mesa3d-dev] [PATCH] Re: master: undef/unmangled EGL functions are part of libOSMesa
Brian Paul bri...@vmware.com writes: Tom wrote: tom fogal wrote: $ lib nm libOSMesa.so | grep EGL U glEGLImageTargetRenderbufferStorageOES U glEGLImageTargetTexture2DOES this prevents using libOSMesa, since one gets link errors about the symbol. Regenerating gl_mangle.h was all that was needed. Thanks for the hint, I've committed the regenerated file. This needed application to 7.8 as well. I generated the patch again on top of 7.8's HEAD, though I think it's the same. My commit bit went through. Symbol mangling updates seem trivial and recurring; can I just commit them? -tom From 292a9e83750d3fe86a492a05a2bde10a8a7c43c5 Mon Sep 17 00:00:00 2001 From: Tom Fogal tfo...@alumni.unh.edu Date: Thu, 25 Mar 2010 16:48:59 -0600 Subject: [PATCH] Regenerate gl_mangle.h --- include/GL/gl_mangle.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index b292840..43d2e89 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -393,6 +393,8 @@ #define glEdgeFlagPointerListIBM MANGLE(EdgeFlagPointerListIBM) #define glEdgeFlagPointer MANGLE(EdgeFlagPointer) #define glEdgeFlagv MANGLE(EdgeFlagv) +#define glEGLImageTargetRenderbufferStorageOES MANGLE(EGLImageTargetRenderbufferStorageOES) +#define glEGLImageTargetTexture2DOES MANGLE(EGLImageTargetTexture2DOES) #define glElementPointerAPPLE MANGLE(ElementPointerAPPLE) #define glElementPointerATI MANGLE(ElementPointerATI) #define glEnableClientStateIndexedEXT MANGLE(EnableClientStateIndexedEXT) -- 1.7.0.2 -- 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] Re: master: undef/unmangled EGL functions are part of libOSMesa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tom fogal wrote: Brian Paul bri...@vmware.com writes: Tom wrote: tom fogal wrote: $ lib nm libOSMesa.so | grep EGL U glEGLImageTargetRenderbufferStorageOES U glEGLImageTargetTexture2DOES this prevents using libOSMesa, since one gets link errors about the symbol. Regenerating gl_mangle.h was all that was needed. Thanks for the hint, I've committed the regenerated file. This needed application to 7.8 as well. I generated the patch again on top of 7.8's HEAD, though I think it's the same. My commit bit went through. Symbol mangling updates seem trivial and recurring; can I just commit them? That should be fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkur6jkACgkQX1gOwKyEAw949gCeLAmCk6eQLPRMz2XFgD3JRHxW igcAnjBmI3WTsdpU1DUv/95R/iGc8u95 =pYK9 -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
Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so
On Thu, Mar 25, 2010 at 9:49 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis gsapount...@gmail.com wrote: On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet again for clarity. 0004 moves the common files into a common directory. I think that it may be better to just consolidate dri_screen.c / dri_context.c / dri_drawable.c / dri_extension.c in a single file named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib state_tracker. There is not much left in the above files after splitting out version-specific code. Then you will have: dri_api.c or dri_driver_api.c for the DRI window system binding dri_st_api.c and dri1.c dri2.c drisw.c for the different versions the only outlier is dri1_helper which I agree may have a better name. But then I looked at this a lot lately and your suggestion may be better for someone looking at it after some time. I think you can do both, the moving of the files is more for making it blatantly clear what is going on. The common files live in the common directory and the rest are in their own directory. This mirrors what is done in egl. I'm ambivalent about grouping the files together. And I don't think that moving them it a common directory stops us from doing either one. Then again dri_extension.c is quite useless, and should probably be moved into dri_screen either way. Are you strongly against the layout that I suggested? I have no real problem with doing both? Ah ok, then the suggested layout serves well its purpose. Wrt to consilidating in dri_driver_api.c (dri_util.c is effectively dri_api.c), it depends on what your plans are for st/dri and if it involves adding more common code, I don't have other plans for st/dri :-) I'll add a comment about the ifdef's (srceen / swap_buffers in dri_screen.c, flush_front / alloc_buffers in dri_st_api.c) and to drisw_util.h about its relationship to dri_util.h . One thing that could be done to reduce the amount of #ifdefs would be to move the tables from dri_screen.c into drisw.c and dri2.c. yes, this could be done unless the suggestion above is adopted, in which case I thinks it's probably better to keep all the dri_ functions static and the _DriverAPI tables in the common file. There is only one function that is static that is used in the tables, or are you meaning that we should make them static as we move all of them into a single file? yes, if we move them all to dri_driver_api.c then it makes more sense to make them static and keep _DriverAPI in dri_driver_api.c with an ifdef. -- 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] [RFC] Draw module patch and BGRA fix for i915g
Jakob Bornecrantz wrote: Hi Brian, Keith, Zack et al. So I tried to get i915g running again and it looks like there is a RGBA vs BGRA bug in the draw module. I have attached two patches that I would like to have some comments on before commit. Patch 1 removes a bunch of switch cases that was strew all over the draw module that all pretty much did exactly the same thing. Which made it hard to fix the RGBA issue for i915g. In draw_pipe_vbuf and draw_pt_emit the format for EMIT_4UB was one thing and in draw_pt_fetch_emit it was another. In light of the format clean up I standardized on following the same as the float formats for EMIT_4UB. Patch 2 then introduces EMIT_4UB_BGRA and is used by i915g to make the colors look correct again. Comments please. Cheers Jakob. The new translsation function: static INLINE unsigned draw_translate_vinfo_format_size(unsigned format) and the existing: static INLINE unsigned draw_translate_vinfo_format(unsigned format ) should probably both take a 'enum attrib_emit' instead of unsigned int. Also, the default switch cases should probably have an assert(0 unexpected format) in case someone were to add a new format value but forget to update the helper functions. Looks good otherwise. -Brian -- 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] Separate demos repository
Eric Anholt wrote: People that hang out on IRC have probably heard about my build system work. One of the first steps I've been working on finishing is splitting out the demos repository. We're currently distributing the Mesa progs/ separately from the main Mesa distribution, and most people aren't installing it, so from a distribution perspective it doesn't make sense to be in the same repository. On the other hand, for driver developers that are having to make clean on a regular basis, wiping out the programs (if you even use them) doesn't help since the programs aren't really changing. And if they are, when you're bisecting around trying an app, you don't want the app changing at the same time. So, I've made a branch in my Mesa repository for a split of the progs/ From Mesa. git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch Open issues: Right now they don't install in general, but it would be easy to change if people are interested in a package that does. I've tested a bunch of them in tree and they seem fine. I've only tested the build on Linux with GL. The GLES stuff needs to get hooked up (I don't see a GLES implementation to test against or I would have). I don't know what to do about the progs/gallium. progs/gallium/unit looks like it should probably live in the Mesa tree next to the code that it's unit testing. progs/gallium/python/ though? None of the GLEW or GLUT is brought along with the apps. It looks to me like all OSes should have libGLEW and libfreeglut reasonably available. I'm not sure if we want the repository to contain all of previous Mesa history. Right now that history costs 145MB on disk for a deep checkout. If that's a problem for people, we could use the same tool that xcb did whose name I forget to to construct a history of just progs/ Where to go from here: If there isn't violent objection to this, I want to get this into place in /git/mesa/demos in a couple of weeks, and then remove those components from the main Mesa repository, plus the things that are only in there because progs depend on them (GLUT, GLEW). In general I'm ok with putting the demos in a separate repo. I probably won't have time to look at your branch for a week or two though. I definitely want to keep the Mesa/Kilgard version of GLUT around. freeglut behaves differently than Mesa's GLUT in a few ways. I still don't trust the former as much as the later. It only takes a miniscule amount of space and builds in 2-3 seconds. We need to go through the progs/tests and see which are unit tests better suited to living with Mesa rather than a separate demo repo. Maybe Chia-I Wu can help out with the OpenGL ES / Open VG programs. I'd appreciate it if you'd hold off on any changes for a little while longer. Thanks. -Brian -- 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
On Thu, Mar 25, 2010 at 11:22 PM, George Sapountzis gsapount...@gmail.com wrote: On Thu, Mar 25, 2010 at 9:49 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis gsapount...@gmail.com wrote: On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet again for clarity. 0004 moves the common files into a common directory. I think that it may be better to just consolidate dri_screen.c / dri_context.c / dri_drawable.c / dri_extension.c in a single file named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib state_tracker. There is not much left in the above files after splitting out version-specific code. Then you will have: dri_api.c or dri_driver_api.c for the DRI window system binding dri_st_api.c and dri1.c dri2.c drisw.c for the different versions the only outlier is dri1_helper which I agree may have a better name. But then I looked at this a lot lately and your suggestion may be better for someone looking at it after some time. I think you can do both, the moving of the files is more for making it blatantly clear what is going on. The common files live in the common directory and the rest are in their own directory. This mirrors what is done in egl. I'm ambivalent about grouping the files together. And I don't think that moving them it a common directory stops us from doing either one. Then again dri_extension.c is quite useless, and should probably be moved into dri_screen either way. Are you strongly against the layout that I suggested? I have no real problem with doing both? Ah ok, then the suggested layout serves well its purpose. Wrt to consilidating in dri_driver_api.c (dri_util.c is effectively dri_api.c), it depends on what your plans are for st/dri and if it involves adding more common code, I don't have other plans for st/dri :-) Thanks, pushed. I don't know, I thought about trying to add EGL Image support to st/dri once it lands in st_api.h and st/egl. And thinking about it I'm leaning more towards keeping them separated. This is the traditionalist in me speaking, keeping code related to one object in each file (screen, context, drawable). This keeps things in line with the rest of the traditional dri drivers. We could merge in dri_extensions.c into dri_context.c and dri_st_api.c into dri_drawable.c and dri_screen.c, if it is the amount of files that you are worried about (in fact I prefer that over just keeping at as it is). Also I files above 1k loc board always feels a bit intimating :-). Then again this is not a strong feeling, so if you have strong opinions or it hampers your development please go ahead and change. Some improvement should be made tho. I'll add a comment about the ifdef's (srceen / swap_buffers in dri_screen.c, flush_front / alloc_buffers in dri_st_api.c) and to drisw_util.h about its relationship to dri_util.h . One thing that could be done to reduce the amount of #ifdefs would be to move the tables from dri_screen.c into drisw.c and dri2.c. yes, this could be done unless the suggestion above is adopted, in which case I thinks it's probably better to keep all the dri_ functions static and the _DriverAPI tables in the common file. There is only one function that is static that is used in the tables, or are you meaning that we should make them static as we move all of them into a single file? yes, if we move them all to dri_driver_api.c then it makes more sense to make them static and keep _DriverAPI in dri_driver_api.c with an ifdef. With the -fvisibility=invisible flag given to gcc all those symbols are pretty much static. Again not strong opinions. Thanks again for the work you did. Cheers Jakob. -- 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] [Bug 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB
http://bugs.freedesktop.org/show_bug.cgi?id=27312 --- Comment #2 from Brian Paul brian.e.p...@gmail.com 2010-03-25 17:17:14 PST --- Which driver are you using? swrast or softpipe or other? I could probably look into this as soon as you provide a (glut) test program. -- 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
[Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)
Hi, http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build mklib: Making Linux shared library: swrastg_dri.so.tmp gcc -o swrastg_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o swrastg_dri.so.tmp -L/home/cjb/xorg-build/lib -ldrm -lexpat -lm -lpthread -ldl swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4' swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4' (Only seen on sparc64.) -- Chris Ball c...@laptop.org One Laptop Per Child -- 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] [RFC] Draw module patch and BGRA fix for i915g
On Thu, Mar 25, 2010 at 11:52 PM, Brian Paul bri...@vmware.com wrote: Jakob Bornecrantz wrote: Hi Brian, Keith, Zack et al. So I tried to get i915g running again and it looks like there is a RGBA vs BGRA bug in the draw module. I have attached two patches that I would like to have some comments on before commit. Patch 1 removes a bunch of switch cases that was strew all over the draw module that all pretty much did exactly the same thing. Which made it hard to fix the RGBA issue for i915g. In draw_pipe_vbuf and draw_pt_emit the format for EMIT_4UB was one thing and in draw_pt_fetch_emit it was another. In light of the format clean up I standardized on following the same as the float formats for EMIT_4UB. Patch 2 then introduces EMIT_4UB_BGRA and is used by i915g to make the colors look correct again. Comments please. Cheers Jakob. The new translsation function: static INLINE unsigned draw_translate_vinfo_format_size(unsigned format) and the existing: static INLINE unsigned draw_translate_vinfo_format(unsigned format ) should probably both take a 'enum attrib_emit' instead of unsigned int. Done. Also, the default switch cases should probably have an assert(0 unexpected format) in case someone were to add a new format value but forget to update the helper functions. Done. Looks good otherwise. Thanks for the review, pushed to master. Cheers Jakob. -- 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] Current tinderbox regression (swrastg_dri, sparc64)
On Fri, Mar 26, 2010 at 2:23 AM, Chris Ball c...@laptop.org wrote: Hi, http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build mklib: Making Linux shared library: swrastg_dri.so.tmp gcc -o swrastg_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o swrastg_dri.so.tmp -L/home/cjb/xorg-build/lib -ldrm -lexpat -lm -lpthread -ldl swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4' swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4' (Only seen on sparc64.) my guess is that glapi uses sync primitives (see glthread.h) and the test is done against stubs which does not contain these primitives. it should be possible to build the real libglapi.a first (by adding a Makefile in src/mesa/glapi) and then do the link test using the real libglapi.a -- 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] Current tinderbox regression (swrastg_dri, sparc64)
Are you sure that swrastg and/or any Gallium driver actually load correctly and work on sparc64? This seems to indicate that they use __sync_add_and_fetch_4 assuming it is a GCC builtin, but GCC does not implement it as a builtin on sparc64 and neither libgcc nor libc have an implementation of the function. I don't know anything about sparc64, but according to the linux kernel, I vaguely guess that specifying an high enough -march= to gcc could solve it by enabling use of atomic instructions that are otherwise are not used. The root cause is likely that we set PIPE_ATOMIC_GCC_INTRINSIC even though not all __sync builtins are actually supported: we should probably fix that. -- 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
