Re: [Mesa3d-dev] mesa-8.0.x: Cherry-pick dri/nouveau: don't use nested functions
On 01/17/2013 02:14 PM, Sedat Dilek wrote: Hi I am playing again with llvm/clang v3.2 and patches I adapted from LLVMLinux project. I wanted to test my new toolchain before doing a rough testing of the mainline Linux-kernel. I decided to build the latest mesa-8.0.5 as I am on Ubuntu/precise AMD64 here by making me and my build-deps happy (so NO mesa-9.x as it requires a higher version of libdrm). Unfortunately, I hit the same problem Johannes Obermayr already described. Gratefully he points also in the BTS to the patch which is NOT in 8.0 mesa GIT branch! Thank you Johannes. Can someone cherry-pick this one? commit 4aa1ac5fe94b5696095229ee3568bf4fa7cfed95 dri/nouveau: don't use nested functions Done. -Brian -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa-8.0.5: LLVM-3.2 patchset and request for cherry-picking
On 01/17/2013 04:23 PM, Sedat Dilek wrote: Hi, with the following patchset (13 patches) I was able to build mesa-8.0.5 with LLVM v3.2. There is one big fat patch called gallivm,draw,llvmpipe: Support wider native registers. [1] which makes backporting hard. Jose? Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=3469715 P.S.: Patchset fixing build of mesa-8.0.5 with LLVM/CLANG v3.2 [ gallium-auxiliary-fixes-for-8-0-5 (PENDING) ] 4b7b71a rtti was removed from more llvm libraries. Thanks to d0k for the hint via IRC #llvm on irc.oftc.net For more details see [1] and followup [2] discussion (Thanks Johannes Obermayr again)! [1] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029167.html [2] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029184.html [ gallivm-fixes-for-8-0-5 (CHERRY-PICKED) ] 920a940 gallivm: Fix createOProfileJITEventListener namespace with llvm-3.1. d998daf gallivm: Add constructor for raw_debug_ostream. af1f68a gallivm: Add MCRegisterInfo.h to silence benign warnings about missing implementation. ad88aac gallivm: Pass in a MCInstrInfo to createMCInstPrinter on llvm-3.1. 395c791 gallivm: Fix method overriding in raw_debug_ostream. 557632f gallivm: Use InitializeNativeTargetDisassembler(). 6c0144a gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1. 1bb5b0d gallivm: Initialize x86 disassembler on x86_64 too. 4d25e57 gallivm: Replace architecture test with PIPE_ARCH_* 192859a gallivm: Fix LLVM-2.7 build. 2dfd7e5 Initialize only native LLVM Disassembler. [ dri-nouveau-fixes-for-8-0-5 (CHERRY-PICKED) ] abd8713 dri/nouveau: don't use nested functions - EOT - Why are you using mesa 8.0.5? Wouldn't it be better to get into 9.x or master (aka 9.1)? -Brian -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Compiling Mesa from git (just build, not installed)
On Sun, May 8, 2011 at 3:01 AM, STEVE555 stevenward...@hotmail.com wrote: Hi to all, I have been regularly been building the git version of mesa with with the gallium-nouveau code enabled. I'm currently using Fedora Rawhide with the latest updates. I use the following ./autogen.sh options to set mesa for the build: ./autogen.sh --enable-debug --enable-glx-tls --enable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-i915 --disable-gallium-i965 --disable-egl --disable-gallium-r300 --disable-gallium-r600 --disable-gallium-svga --with-state-trackers=glx,dri(and I sometimes add the xorg-state-tracker at the end). The trouble I'm having is after I believe after some commits for GLX, Mesa keeps ending with this build error: DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\/usr/local/lib/dri\ glxcmds.c -o glxcmds.o gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa -I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -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 -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\/usr/local/lib/dri\ glxcurrent.c -o glxcurrent.o gcc -c -I. -I../../include -I../../include/GL/internal -I../../src/mesa -I../../src/mapi -I../../src/mapi/glapi -I/usr/include/libdrm -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -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 -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden -DXF86VIDMODE -D_REENTRANT -DDEFAULT_DRIVER_DIR=\/usr/local/lib/dri\ glxext.c -o glxext.o glxext.c: In function ‘__glXWireToEvent’: glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member named ‘sbc_hi’ glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member named ‘sbc_lo’ gmake[2]: *** [glxext.o] Error 1 gmake[2]: Leaving directory `/opt/mesa/src/glx' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/opt/mesa/src' gmake: *** [default] Error 1 I have waited for a few days to see if the problem had been solved after some new commits, but I haven't noticed any, so I wanted to report my problem here. You might need new glproto header files. I think there's been some protocol fixes recently. -Brian -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72
On Sat, Apr 23, 2011 at 5:15 PM, Dave Airlie airl...@gmail.com wrote: Hi Brian, st/mesa: check image size before copy_image_data_to_texture() This causes a regression with NPOT textures in fbo-generate-mipmaps on r600g. You meant fbo-generate-mipmap-formats right? fbo-generate-mipmaps works for me. -Brian -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Draw module optimizations
On 01/23/2011 10:30 PM, Jakob Bornecrantz wrote: Hi all I have pushed some draw module changes here http://cgit.freedesktop.org/~wallbraker/mesa/log/?h=i915g-speedshowmsg=1 which improves speed in the draw module by avoiding unneeded flushing and setup on draw calls. The first two commits (starting from the bottom, right after master) doesn't yield much improvements especially after the last commit. Remove_reduce_prim is required as any call to draw_do_flush would result in the following call draw_vbo would be called with STATE_CHANGE, which with the last commit would call into prepare when it is not needed. The last commit is the one that does the biggest difference. As it is the one that stops prepare from being called on every draw_vbo call. And as a side effect removes the last draw_do_flush call, enabling at last the pipeline to gather up vertices from several draw_vbo calls into a single draw_elements. The paste below shows the difference, first column are from the test application (tests/step that I just pushed), the rest are either from i915g or draw, it should be obvious which is which. http://pastebin.com/5i3BejgJ A follow up to these changes would be try to unify draw_pipe_vbuf and draw_pt_emit into a single file or to refractor code into a single vbuf primitive collector that would allow draw_arrays calls to be grouped into a single vbuf_render-draw_arrays call (provided primitive can be combined). This would improve draw_pt_emit_run_linear performance on draw heavy applications. I guess one could also look into merging draw_elements with each other by manipulating indices (between draw_pt_emit and the pipeline). As well as draw_arrays and draw_elements by doing the same. Comments please. Jakob, I pulled your branch and tested with piglit with llvmpipe. Looks like there's a number of regressions in the general catagory: general/bgra-sec-color-pointer general/bgra-vert-attrib-pointer general/draw-batch general/draw-elements general/draw-vertices general/primitive-restart etc. You can run this group of tests with: ./piglit-run.py -t ^general tests/all.tests results/new I suspect that either the reduced prim removal or one of the new conditionals put around the flushing code is at fault. Otherwise, this patch series looks like good stuff. -Brian -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model
Christoph, I don't see a patch for the st/mesa program translation code to check that we don't exceed the limit. Were you doing to take care of that too? I guess we're assuming that the max number of generic inputs == max number of generic outputs. I think that's OK until a counter case appears. -Brian On 12/17/2010 05:28 AM, Keith Whitwell wrote: Christoph, This looks good. Thanks for bringing this back to life. Keith On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote: On 12/14/2010 12:36 PM, Keith Whitwell wrote: On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote: I want to warm this up again adding nvc0 and GL_ARB_separate_shader_objects to the picture. The latter extends GL_EXT_separate_shader_objects to support user defined varyings and guarantees well defined behaviour only if - varyings are declared inside the gl_PerVertex/gl_PerFragment block the blocks match exactly in name, type, qualification, and (most significantly) declaration order. - varyings are assigned matching location qualifiers: like: layout(location = 3) in vec4 normal The number of input locations available to a shader is limited. So, I propose to (loosely) identify GENERIC semantic indices with these location qualifiers and let the pipe driver set a limit on the allowed maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least support 219 of them - nvc0 offsers 0x200 bytes for generic inputs/outputs). This sounds fine actually. We kicked this around before I was basically ok with the last iteration of the proposal, but this seems ok too. As far as I can tell from a gallium perspective you're really just proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would be clearer), which the state tracker thereafter has to respect? That would be fine with me. First attempt at a patch introducing such a cap attached. My motivation is mostly that the hardware routing table for shader varyings that was present on nv50 has been removed with nvc0 (Fermi). And I'm glad, because filling 4 routing tables (since we have 5 shader types now) is somewhat annoying. And so applying relocations to shaders - it can be done, it's probably not too time consuming, but it's just plain *unnecessary* (and thus stupid) for OpenGL. Now about d3d9 ... 1. don't care, I don't see a d3d9 state tracker 2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx says n is an optional integer between 0 and the number of resources supported - what supported means here isn't clear to me, but, I didn't find any example where someone used something OpenGL doesn't have (like COLOR2). 3. http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics says Input semantics are similar to the values in the D3DDECLUSAGE. and DECLUSAGE sounds like you're limited to sane values. I think you're on the right track with (1)... It's fairly pointless trying to discuss code here which isn't public I don't think people need to be worrying about what may or may not be important for code they can't see. I know this idea previously got tied up with speculation about what a DX9 state tracker might or might not require, but in retrospect I wish I'd been able to steer conversation away from that. The work on closed components may drive a lot of the feature development and new interfaces, but there's usually enough flexibility that this sort of cleanup isn't a big deal. Keith Not sure if anyone wants to think about this issue at this time (since implementation of ARB_separate_shader_objects is probably far in the GL4 future), but I'd be happy about any comments. Regards, Christoph On 04/13/2010 12:55 PM, Luca Barbieri wrote: This patch series is intended to resolve the issue of semantic-based shader linkage in Gallium. It can also be found in the RFC-gallium-semantics branch. It does not change the current Gallium design, but rather formalizes some limitations to it, and provides infrastructure to implement this model more easily in drivers, along with a full nv30/nv40 implementation. These limitations are added to allow an efficient implementation for both hardware lacking special support and hardware having support but also special constraints. Note that this does NOT resolve all issues, and there are quite a bit left to future refinement. In particular, the following issues are still open: 1. COLOR clamping (and floating point framebuffers) 2. A linkage table CSO allowing to specify non-identity linkage 3. BCOLOR/FACE-related issues 4. Adding a cap to inform the state tracker that more than 219 generic indices are provided This topic was already very extensively discussed. See http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10865.html for some early inconclusive discussion around an early implementation that modified the GLSL linker (which is NOT being
Re: [Mesa3d-dev] Building mesa: undefined references to 'sl_pp' etc.
Matej Urbas wrote: Hi, I am trying to build mesa. I did this: ./autogen.sh gmake All dependencies are satisfied and 'autoreconf' passes without complaints. However, I get the following build-time error: mklib: Making Linux shared library: i810_dri.so.tmp gcc -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 -DFEATURE_GL=1 -o i810_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o i810_dri.so.tmp -ldrm -lexpat -lm -lpthread -ldl i810_dri.so.tmp: undefined reference to `sl_pp_version' i810_dri.so.tmp: undefined reference to `sl_pp_context_destroy' i810_dri.so.tmp: undefined reference to `sl_cl_compile' i810_dri.so.tmp: undefined reference to `sl_pp_context_create' i810_dri.so.tmp: undefined reference to `sl_pp_context_error_message' i810_dri.so.tmp: undefined reference to `sl_pp_context_add_extension' collect2: ld returned 1 exit status gmake[6]: *** [i810_dri.so] Error 1 gmake[6]: Leaving directory `myfolder/mesa/src/mesa/drivers/dri/i810' gmake[5]: *** [lib] Error 2 gmake[5]: Leaving directory `myfolder/mesa/src/mesa/drivers/dri/i810' gmake[4]: *** [subdirs] Error 1 gmake[4]: Leaving directory `myfolder/mesa/src/mesa/drivers/dri' gmake[3]: *** [default] Error 1 gmake[3]: Leaving directory `myfolder/mesa/src/mesa/drivers' gmake[2]: *** [driver_subdirs] Error 2 gmake[2]: Leaving directory `myfolder/mesa/src/mesa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `myfolder/mesa/src' gmake: *** [default] Error 1 Could I please ask you for some info on how to alleviate the problem? Nobody else has reported this, AFAIK. Did you try a 'make clean' first? -Brian -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.8.2 release?
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like a few bug fixes have accumulated on the branch. Could folks spend some time this week to cherry-pick stable patches from master, update the release notes, etc. so that we can do a release either on Friday or Monday? Sounds good. In theory it should be fine to make a new release off of the stable branch at almost any time. I've got a couple patches to cherry-pick... -Brian -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] softpipe: Fix division by zero
Arpad Borsos wrote: Sorry about my last mail which was empty except for the attached patch. The patch fixes a division by zero crash which is triggered when I run the cairo test-suite using its gl backend and the gallium softpipe driver. The test-suite still crashes when I'm using llvmpipe, need to look into that. Thanks. I'm committing to the 7.8 branch. Just FYI: the divide by zero results in an inf value here and there but it doesn't seem to effect the rendering outcome (though I've never tested with cairo). -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] [PATCH] demos: import GLSL raytracing demos
It looks like the piglit tests use an image comparison to determine pass/fail, right? That may not be too reliable since different drivers will produce slightly different results. Is there any way that the rendering can be checked for correctness without relying on an exact image comparison? -Brian RALOVICH, Kristóf wrote: Would someone please have a look at this piglit tests? Thanks, Kristof On Sun, Mar 28, 2010 at 17:52, RALOVICH, Kristóf kristof.ralov...@gmail.com wrote: Eric, please see the attached patch for piglit. The patch includes 2 new tests based on the demos I provided for mesa. Let me know if I can further help! Thanks, Kristof On Wed, Mar 24, 2010 at 16:33, Eric Anholt e...@anholt.net wrote: On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf kristof.ralov...@gmail.com wrote: Brian, that was fast! Who do you think I should bug, to get these working on i965? Also as my time allows, I am planning to extend them with mouse input for orientation and arrow keys for moving to camera to become more interactive. Make a testcase for piglit, and I'd love to fix your 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] [PATCH] demos: import GLSL raytracing demos
Suppose a ray just barely hits/misses a sphere. Depending on the GPU arithmetic and whether the outcome is a hit or miss, the resulting pixel color could be completely different. A per-pixel error margin won't account for this. But as you suggested, if you allow a certain number or percent of pixel comparisons to fail, that might do the job here. How about implementing that? I'd also suggest putting the comparison code into a new piglit utility function (or at least put the code in a separate function that could be promoted to piglit-util.c someday). BTW, the piglit_probe_pixel_rgb() function should really take a tolerance parameter, rather than it being hard-coded inside the function. Another piglit utility function to compute tolerances from various parameters would be good... but that's another project. -Brian RALOVICH, Kristóf wrote: Brian, you are right, maybe more freedom should be allowed, but piglit_probe_pixel_rgb() already uses 0.01 as threshold which should be enough if the ray directions do not have large FP differences. As a short term goal with the test vsraytrace was, that it should not take my GM4500 down. As a longer term solution we can allow e.g. 15% of pixels to even fail piglit_probe_pixel_rgb() too. I can extend the patch with this if you'd like it. Kristof On Wed, Apr 14, 2010 at 16:49, Brian Paul bri...@vmware.com wrote: It looks like the piglit tests use an image comparison to determine pass/fail, right? That may not be too reliable since different drivers will produce slightly different results. Is there any way that the rendering can be checked for correctness without relying on an exact image comparison? -Brian RALOVICH, Kristóf wrote: Would someone please have a look at this piglit tests? Thanks, Kristof On Sun, Mar 28, 2010 at 17:52, RALOVICH, Kristóf kristof.ralov...@gmail.com wrote: Eric, please see the attached patch for piglit. The patch includes 2 new tests based on the demos I provided for mesa. Let me know if I can further help! Thanks, Kristof On Wed, Mar 24, 2010 at 16:33, Eric Anholt e...@anholt.net wrote: On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf kristof.ralov...@gmail.com wrote: Brian, that was fast! Who do you think I should bug, to get these working on i965? Also as my time allows, I am planning to extend them with mouse input for orientation and arrow keys for moving to camera to become more interactive. Make a testcase for piglit, and I'd love to fix your 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] Mesa dev list has been moved to fd.o
Thanks to Tollef and Jesse, everyone should now be subscribed to the mesa-dev list at freedesktop.org. You should see this message twice if you're on the new list. I'll probably shut down the old list next week when I get back from a little time off... -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] Mesa (master): st/xorg: Fix bad paramf.
Author: Corbin Simpson mostawesomed...@gmail.com
Date: Fri Apr 9 03:38:23 2010 -0700
st/xorg: Fix bad paramf.
Should be an integer param, according to docs.
---
src/gallium/state_trackers/xorg/xorg_driver.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c
b/src/gallium/state_trackers/xorg/xorg_driver.c
index 8ac5179..d5dd0d7 100644
--- a/src/gallium/state_trackers/xorg/xorg_driver.c
+++ b/src/gallium/state_trackers/xorg/xorg_driver.c
@@ -676,10 +676,8 @@ drv_screen_init(int scrnIndex, ScreenPtr pScreen, int
argc, char **argv)
}
if (ms-screen) {
- float maxf;
int max;
- maxf = ms-screen-get_paramf(ms-screen,
PIPE_CAP_MAX_TEXTURE_2D_LEVELS);
- max = (1 (int)(maxf - 1.0f));
+ max = ms-screen-get_param(ms-screen,
PIPE_CAP_MAX_TEXTURE_2D_LEVELS);
max_width = max max_width ? max : max_width;
max_height = max max_height ? max : max_height;
}
This doesn't look right. The shift line is missing.
PIPE_CAP_MAX_TEXTURE_2D_LEVELS is not a width/height value. To compute the max
width and height from max_levels:
max_width = 1 (max_levels - 1)
-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] Mesa (master): st/egl: Move probe interface to native_probe.h.
One thing below... diff --git a/src/gallium/state_trackers/egl/common/native_probe.h b/src/gallium/state_trackers/egl/common/native_probe.h new file mode 100644 index 000..4ed37a5 --- /dev/null +++ b/src/gallium/state_trackers/egl/common/native_probe.h @@ -0,0 +1,67 @@ +/* + * Mesa 3-D graphics library + * Version: 7.8 + * + * Copyright (C) 2009-2010 Chia-I Wu o...@0xlab.org + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included + * in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN When copying/pasting the license info into new files, check who's named in the license blurb. You can either replace BRIAN PAUL with your name or THE AUTHORS AND COPYRIGHT HOLDERS. 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
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, Apr 8, 2010 at 4:21 PM, Brian Paul bri...@vmware.com wrote: Unless there's some objection I'm going to subscribe everyone to the new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. Probably in the next 24 hours. Then, some of you may have to log into the mailman interface (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest mode, etc. I've sent the subscriber list to Jesse and he's sent it to Tollef. He can preserve the digest vs. regular state with the new list -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] Move lists to freedesktop.org?
Unless there's some objection I'm going to subscribe everyone to the new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. Probably in the next 24 hours. Then, some of you may have to log into the mailman interface (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest mode, etc. -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] Current tinderbox regression (swrast_dri)
On Tue, Apr 6, 2010 at 8:00 PM, Chris Ball c...@laptop.org wrote: http://tinderbox.x.org/builds/2010-04-07-0001/logs/libGL/#build swrastg_dri.so.tmp: undefined reference to draw_pt_fetch_pipeline_or_emit_llvm collect2: ld returned 1 exit status http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae69f9fbf0a1aab7186e5b644085a5fe5aea99af Should be fixed now. -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] [PATCH] fix cell build
On Tue, Apr 6, 2010 at 3:44 PM, Marc Dietrich marvi...@gmx.de wrote: From: root r...@fb07-iapwap2.physik.uni-giessen.de compile fix for cell driver. --- src/gallium/drivers/cell/ppu/cell_screen.c | 3 +++ src/gallium/drivers/cell/ppu/cell_texture.c | 2 +- 2 files changed, 4 insertions(+), 1 deletions(-) Applied. 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] segfault in readpix demo with GL_OES_read_format on r300g
Chia-I Wu wrote: On Mon, Apr 5, 2010 at 7:42 AM, Dave Airlie airl...@gmail.com wrote: Starting program: /home/airlied/mesa/progs/demos/readpix [Thread debugging using libthread_db enabled] GL_VERSION = 2.1 Mesa 7.9-devel GL_RENDERER = Gallium 0.4 on RV530 Program received signal SIGSEGV, Segmentation fault. 0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38) at main/framebuffer.c:1021 1021} Missing separate debuginfos, use: debuginfo-install expat-2.0.1-8.fc12.i686 libICE-1.0.6-1.fc12.i686 libSM-1.1.0-7.fc12.i686 libX11-1.3-1.fc12.i686 libXdamage-1.1.2-1.fc12.i686 libXext-1.1-2.fc12.i686 libXfixes-4.0.4-1.fc12.i686 libXi-1.3-2.fc12.i686 libXmu-1.0.5-1.fc12.i686 libXt-1.0.7-1.fc12.i686 libXxf86vm-1.1.0-1.fc12.i686 libgcc-4.4.3-4.fc12.i686 libstdc++-4.4.3-4.fc12.i686 libuuid-2.16.2-5.fc12.i686 libxcb-1.5-1.fc12.i686 (gdb) bt #0 0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38) at main/framebuffer.c:1021 #1 0xb7d75758 in _mesa_GetIntegerv (pname=35738, params=0x804c41c) at main/get.c:5576 #2 0x080493ae in Init (argc=1, argv=0xb2b4) at readpix.c:354 #3 main (argc=1, argv=0xb2b4) at readpix.c:396 (gdb) I have the segfault with i915g and non-gallium fakeglx. It seems _mesa_Get* should also validate the states before getting these state variables - GL_IMPLEMENTATION_COLOR_READ_TYPE_OES - GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES Yeah, that's it. I'll commit a fix. -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] RFC: GSOC Proposal: R300 GLSL Compiler - 2nd Draft
Nicolai Haehnle wrote: Hi, On Mon, Apr 5, 2010 at 1:58 AM, Tom Stellard tstel...@gmail.com wrote: 1. Improve branch emulation in the r300 compiler: The goal of this task will be to improve upon the work done by Nicolai Häehnle in this branch: http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl and fully support branch emulation in the r300 compiler. This first part of this task will involve testing the current branch emulation code to determine what works and what does not. After this has been completed work can begin on any part of the branch emulation that does not work correctly. You misspelled my name :P 2. Unroll loops in the r300 compiler: The goal of this task will be to unroll loops so that they can be executed by hardware that does not support them. The loop unrolling in this task is not meant as a code optimization. It is only being done to eliminate branch instructions. Loops where the number of iterations are known at compile time will be unrolled and may have additional optimizations applied. Loops that have an unknown number of iterations, will have to be studied to see if there is a way to replace the loop with a set of instructions that produces the same output as the loop. For example, one solution might be to replace an ADD(src0, src0) instruction that is supposed to execute n times with a MUL(src0, n). It is possible that not all loops will be able to be unrolled successfully. It is certain that not all loops will be able to be unrolled successfully, if only due to limits on the number of instruction in a shader ;) For loops with number of iterations determined at runtime, you should check (ask around) for real-life shaders where this is the case. The example you mention sounds unrealistic to me, but I could imagine that there are shaders with an *upper-bound* on the number of iterations known at compile time. Then loops can be unrolled to that upper-bound, and later iterations could be masked off somehow based on the actual desired number of iterations at runtime. See progs/glsl/CH18-mandel.frag for an example: for (iter = 0.0; iter 12.0 r2 4.0; ++iter) I believe the Phoronix Lightsmark demo also uses some loops in its shaders. It's not feasible to unroll all loops but some common cases are doable. -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] mesa: update_arrays() depends on program state.
Henri Verbeet wrote: It uses ctx-VertexProgram._Current. --- src/mesa/main/state.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c index 589029d..b971cc9 100644 --- a/src/mesa/main/state.c +++ b/src/mesa/main/state.c @@ -582,9 +582,6 @@ _mesa_update_state_locked( GLcontext *ctx ) if (new_state _DD_NEW_SEPARATE_SPECULAR) update_separate_specular( ctx ); - if (new_state (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT)) - update_arrays( ctx ); - if (new_state (_NEW_BUFFERS | _NEW_VIEWPORT)) update_viewport_matrix(ctx); @@ -620,6 +617,8 @@ _mesa_update_state_locked( GLcontext *ctx ) new_prog_state |= update_program( ctx ); } + if (new_state (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT)) + update_arrays( ctx ); out: new_prog_state |= update_program_constants(ctx); Looks good. I'll commit shortly. 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] ARB draw buffers + texenv program
Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? The piglit test passes as-is with Mesa/swrast and NVIDIA. It fails with gallium/softpipe both with and w/out your patch. I think that your patch is on the right track. But multiple render targets are still a bit of an untested area in the st/mesa code. One thing: the patch introduces a dependency on buffer state in the texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. Otherwise, I'd like to debug the softpipe failure a bit further to see what's going on. Perhaps you could hold off on committing this for a bit... -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] ARB draw buffers + texenv program
Brian Paul wrote: Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? The piglit test passes as-is with Mesa/swrast and NVIDIA. It fails with gallium/softpipe both with and w/out your patch. I think that your patch is on the right track. But multiple render targets are still a bit of an untested area in the st/mesa code. One thing: the patch introduces a dependency on buffer state in the texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. Otherwise, I'd like to debug the softpipe failure a bit further to see what's going on. Perhaps you could hold off on committing this for a bit... OK, I found/fixed the problem in softpipe. I think your patch is good, but I think we should hold off on committing it to the 7.8 branch until it's tested a bit more (and not delay the 7.8.1 release). Other people should apply it and give it a try. -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] Gallium: EXT_gpu_program_parameters
Marek Olšák wrote: Hi devs, this extensions is extensively used in Wine for obvious performance reasons and is quite popular in the GL community, therefore we should advertise it. All needed code seems to be already in mesa/main, so unless I overlooked something, the patch below is sufficient. Any comments, please? -Marek diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 0118c60..ae5e62b 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -183,6 +183,7 @@ void st_init_extensions(struct st_context *st) ctx-Extensions.EXT_framebuffer_object = GL_TRUE; ctx-Extensions.EXT_framebuffer_multisample = GL_TRUE; ctx-Extensions.EXT_fog_coord = GL_TRUE; + ctx-Extensions.EXT_gpu_program_parameters = GL_TRUE; ctx-Extensions.EXT_multi_draw_arrays = GL_TRUE; ctx-Extensions.EXT_pixel_buffer_object = GL_TRUE; ctx-Extensions.EXT_point_parameters = GL_TRUE; Looks good. There's nothing driver-specific about this extension. -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] How do we init half float tables?
Luca Barbieri wrote: On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca jfons...@vmware.com wrote: Reliability goes both ways: using a global constructor simplifies the problem substantially, but it is only as reliable as the global constructor mechanism itself -- which it's not much given the compiler/linker magic necessary to work. Once it is written and works, it should just work indefinitely, since the C++ ABI relies on it. I also think that we should code generate most constat lookup tables: it avoids the initialization problem, and it saves memory when the SO is loaded in several processes as pages can be shared. Yes, I have done exactly this, for the reasons you describe. The half float tables are now pre-generated by a Python script. For S3TC it is not a real problem: any code that exposes S3TC support needs to check if S3TC (de)compresion support is available before advertising (xxx_screen.c). Checking the support and initialization should be done by a single function. That is, if the libtxc_dxtn.so is not available the s3tc functions should *never* be called. I changed the format code to add a new util_format_is_supported that allows users to query if the util_format code can pack/unpack a given format. That function, if called on an s3tc format, will automatically call the S3TC init function. This way, users of the format helpers no longer need to know about S3TC at all, and it will just work. Even if the util_format_is_supported function is not called before reading/writing an S3TC format, the fetch/pack function pointers are initialized to versions that will autoload the S3TC library. Additionally, the S3TC library may now support only a subset of the formats. This may be even more useful as further compressed formats are added. There are two areas where I'm not totally happy with the approach I did though: 1. Currently upon a successful load of S3TC, we hack the format descriptions to set the is_supported bit to 1. Not sure if it is the best way to do it. 2. If S3TC is not available, the functions just do nothing: this is consistent with other unsupported formats. We may however want to read black pixels, throw an error, or read a special error image instead (I'd suggest having unsupported unpack/pack functions and pointing all unsupported formats to them) Also, I think we should remove all the Mesa internal format code and make it use util_format instead, unless there is really a good reason to duplicate it all. Same thing for util_half. So far, there are no dependencies on Gallium in core Mesa. We've talked about refactoring some of the Gallium code into a separate module that'd be sharable between Gallium and Mesa. The format code would probably fit into that. -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] How do we init half float tables?
On Thu, Apr 1, 2010 at 4:29 PM, Luca Barbieri l...@luca-barbieri.com wrote: The half float conversion code initially used a global C++ constructor to initialize the tables. That fails to work since ld does not get the symbol from the shared library, so I changed to use register a global constructor from C, using GCC- or MSVC-specific code. This is not necessarily the best option, but clearly putting a check in the functions as Corbin did is a bad idea performance-wise. So, how should this be done? Options are: 1. Revert Corbin Simpsons's commit and if anyone complains about an unsupported compiler, implement UTIL_INIT for that compiler too 2a. Write the init module in C++ and use portable global constructor syntax (but with other C++-related problems) 2b. Write an auxiliary file in C++ with a global constructor and reference it from the C init file so the static linker pulls it from the .a 3. Have all modules that need half float conversion directly or indirectly call the init functions in their init code 4. Make the build pregenerate the tables and ship them in the executables Option 1: Pros: just works, other auxiliary modules can use the same system Cons: need to write UTIL_INIT for each compiler, only GCC and MSVC (and compatible ones) are currently supported Option 2a: Pros: no compiler-specific UTIL_INIT Cons: significant code written in C++ instead of C and you must link all targets with a C++ compiler or use compiler-specific options to prevent stuff like the G++ personality causing the link to fail Option 2b: Like option 2a, but Pro: less code written in C++ Con: need an extra C++ file for every module with data to be initialized Option 3: Pros: none of the cons of the other options Cons: cumbersome to do, must not forget to call the init function or you get silent corruption. Init calls creep through the whole codebase. Option 4: Pros: no need to do anything at runtime, pages can be shared between OpenGL apps Cons: need to write a special table generator, all DRI drivers get 10KB larger, solution does not apply to all similar problems I would lean for either option 1 or option 4, perhaps option 4 considering there seems to be disagreement over option 1. Option 4 however is likely not universally applicable (not everything can necessarily be pregenerated), so I'd keep the UTIL_INIT code anyway. Which one do we pick? #3. Yeah, in this day and age we should have a nice way to do global constructors but we don't. This solution is simple. A debug-only assert could be used to check that the table's initialized. It's not that big of deal. -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] GSOC: Gallium R300 driver
This is getting off-topic, but anyway...
Luca Barbieri wrote:
There are several deep challenges in making TGSI - LLVM IR translation
lossless -- I'm sure we'll get around to overcome them -- but I don't
think that using LLVM is a requirement for this module. Having a shared
IR for simple TGSI optimization module would go a long way by itself.
What are these challenges?
Control flow is hard. Writing a TGSI backend for LLVM would be a lot
of work. Etc.
If you keep vectors and don't scalarize, I don't see why it shouldn't
just work, especially if you just roundtrip without running any
passes.
The DAG instruction matcher should be able to match writemasks,
swizzles, etc. fine.
Control flow may not be exactly reconstructed, but I think LLVM has
control flow canonicalization that should allow to reconstruct a
loop/if control flow structure of equivalent efficiency.
LLVM only has branch instructions while GPU instruction sets avoid
branching and use explicit conditional and loop constructs. Analyzing
the LLVM IR branches to reconstruct GPU loops and conditionals isn't easy.
Using LLVM has the obvious advantage that all optimizations have
already been written and tested.
And for complex shaders, you may really need a good full optimizer
(that can do inter-basic-block and interprocedural optimizations,
alias analysis, advanced loop optmizations, and so on), especially if
we start supporting OpenCL over TGSI.
There is also the option of having the driver directly consume the
LLVM IR, and the frontend directly produce it (e.g. clang supports
OpenCL - LLVM).
Some things, like inlining, are easy to do directly in TGSI (but only
because all regs are global).
Inlining isn't always easy. The Mesa GLSL compiler inlines function
calls whenever possible. But there are some tricky cases. For
example, if the function we want to inline has deeply nested early
return statements you have to convert the return statements into
something else to avoid mistakenly returning from the calling
function. The LLVM optimizer may handle this just fine, but
translating the resulting LLVM IR back to TGSI could be hard (see above).
However, even determining the minimum number of loop iterations for
loop unrolling is very hard to do without a full compiler.
For instance, consider code like this:
if(foo = 6)
{
if(foo == 1)
iters = foo + 3;
else if(bar == 1)
iters = foo + 5 + bar;
else
iters = foo + 7;
for(i = 0; i iters; ++i) LOOP_BODY;
}
You need a non-trivial optimizer (with control flow support, value
range propagation, and constant folding) to find out that the loop
always executes at least 12 iterations, which you need to know to
unroll it optimally.
More complex examples are possible.
Yup, it's hard.
It general, anything that requires (approximately) determining any
property of the program potentially benefits from having the most
complex and powerful optimizer available.
I also think that some optimizations are more effective if they're
applied at a higher level (in the GLSL compiler, for example). But
that's a another topic of conversation.
-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] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Final versions of both Mesa 7.8 and 7.7.1 have been released. Links on the Mesa website will still need to be updated, but I think Brian has to do that. I'll do that soon. The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'. I had originally intended to just use 7.8, but having a tag and a branch with the same name makes GIT angry (i.e., you get warning: refname '7.8' is ambiguous.). Yeah, that's what I'm getting now - and I can't seem to update my 7.8 branch to the latest commit: $ git rebase origin/7.8 warning: refname '7.8' is ambiguous. Current branch 7.8 is up to date. I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now. Help? -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] [PATCH] glsl: optimize sqrt
Roland Scheidegger wrote: On 29.03.2010 04:50, Marek Olšák wrote: We were talking a bit on IRC that the GLSL compiler implements the sqrt function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as is in the original code, the proposed patch uses just rsq+mul. Please see the patch log for further explanation, and please review. I'll definitely agree with the mul instead of rcp part, as that should be more efficient on a lot of modern hardware (rcp usually being part of some special function block instead of main alu). As far as I can tell though we still need the cmp unfortunately, since invsqrt(0) is infinite and multiplying by 0 will give some undefined result, for IEEE it should be NaN (well depending on hardware I guess, if you have implementation which clamps infinity to its max representable number it should be ok). In any case, glsl says invsqrt(0) is undefined, hence can't rely on this. Yeah, I'm going to keep the x==0 test for now. I'm replacing the rcp with mul, per Marek's idea. Thanks, Marek! Thinking about it, we'd possibly want a SQRT opcode, both in mesa and tgsi. Because there's actually hardware which can do sqrt (i965 MathBox), and just as importantly because this gives drivers a way to implement this as invsqrt + mul without the cmp, if they can. For instance AMD hardware generally has 3 rounding modes for these ops, IEEE (which gives infinity for invsqrt(0)), DX (clamps to MAX_FLOAT), and FF (which clamps infinity to 0, exactly what you need to implement sqrt with a mul and invsqrt and no cmp - though actually it should work with DX clamping as well). I'd be happy to see a new SQRT instruction. I'll put it on my to-do list. -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] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Final versions of both Mesa 7.8 and 7.7.1 have been released. Links on the Mesa website will still need to be updated, but I think Brian has to do that. I'll do that soon. The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'. I had originally intended to just use 7.8, but having a tag and a branch with the same name makes GIT angry (i.e., you get warning: refname '7.8' is ambiguous.). Yeah, that's what I'm getting now - and I can't seem to update my 7.8 branch to the latest commit: $ git rebase origin/7.8 warning: refname '7.8' is ambiguous. Current branch 7.8 is up to date. I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now. Help? Hmm... I did 'git tag -d 7.8' and that fixed the problem locally. I thought pushing tags afterwards would delete the remote tag, but apparently not. I'll try to solve that today. OK, git tag -d 7.8 fixed the problem here. -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] [Mesa3d-announce] Mesa 7.7.1 and Mesa 7.8 released!
Brian Paul wrote: Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Final versions of both Mesa 7.8 and 7.7.1 have been released. Links on the Mesa website will still need to be updated, but I think Brian has to do that. I'll do that soon. The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'. I had originally intended to just use 7.8, but having a tag and a branch with the same name makes GIT angry (i.e., you get warning: refname '7.8' is ambiguous.). Yeah, that's what I'm getting now - and I can't seem to update my 7.8 branch to the latest commit: $ git rebase origin/7.8 warning: refname '7.8' is ambiguous. Current branch 7.8 is up to date. I'm stuck at commit 59258498dc6fa51573b176d071644bd3e750b5ac now. Help? Hmm... I did 'git tag -d 7.8' and that fixed the problem locally. I thought pushing tags afterwards would delete the remote tag, but apparently not. I'll try to solve that today. OK, git tag -d 7.8 fixed the problem here. Grrr, the 7.8 tag comes back after a git-fetch though. -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] [PATCH] glGet: Optimize glGet calls by avoiding redundant state updates
Following up on an message from a while ago:
Brian Paul wrote:
Robert Bragg wrote:
Hi,
Every now and then while working on the Clutter toolkit we end up with
glGet{Integer,Float}v in our profiles. Our typical response is to simply
cache the offending state so as to avoid querying OpenGL, but it feels
like this is papering over the problem.
I've attached a patch that instead tries to address the performance
problem in Mesa and hoping something like this could be accepted
upstream?
Coincidentally, I was looking at this just recently.
It would be a good change to make. Though I think I'd add a new flag to
the StateVars table entries to indicate whether the state requires
validation (and what state). Then auto-generate the needed code.
So GL_RED_BITS case would be predicated like this:
case GL_RED_BITS:
if (ctx-NewState _NEW_BUFFERS)
_mesa_update_state(ctx);
params[0] = ctx-DrawBuffer-Visual.redBits;
break;
_NEW_BUFFERS would be a new field in the StateVars list.
Most state queries don't need validation. The ones that do are the ones
that you patched plus the current attribs (_NEW_CURRENT_ATTRIB).
Maybe a few others?
Are you interested in coding this up?
I've implemented change this and will be committing it soon.
-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] [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] [PATCH] demos: import GLSL raytracing demos
RALOVICH wrote: Brian, that was fast! Who do you think I should bug, to get these working on i965? Eric Anholt has been working on the i965 driver. I wouldn't bug him too much though. He's pretty busy. Also as my time allows, I am planning to extend them with mouse input for orientation and arrow keys for moving to camera to become more interactive. OK, ignore my other msg then. -Brian Thanks, Kristof On Wed, Mar 24, 2010 at 11:04, Brian Paul bri...@vmware.com wrote: RALOVICH wrote: Attached patch adds to glsl demos to mesa. If the drivers support them, these might give better performance numbers than glxgears. Currently both works fine with swrast, but neither works on i965. Corresponding active bug reports: https://bugs.freedesktop.org/show_bug.cgi?id=26691 https://bugs.freedesktop.org/show_bug.cgi?id=27060 Please apply! Done, with minor fixes. 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] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0
Luca Barbieri wrote: Apparently _mesa_Clear should not set BUFFER_BIT_STENCIL if the visual lacks a stencil buffer. So it seems the visual is somehow incorrect, or a visual with a stencil buffer is being selected but the stencil renderbuffer is not actually set. At line 167 of src/mesa/main/clear.c we check if the user specifies GL_STENCIL_BUFFER_BIT but the drawing surface has no stencil bits. So, st_clear() should not be getting BUFFER_BIT_STENCIL if there's no stencil buffer. Perhaps you could debug that a bit further. -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] [PATCH] st/mesa: make st_manager.c set have[Stencil|Depth]Buffer only if bits 0
Luca Barbieri wrote:
Fixes a segfault when clearing a non-existent stencil buffer.
---
src/mesa/state_tracker/st_manager.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index ca3a29c..cac62e4 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -333,15 +333,15 @@ st_visual_to_context_mode(const struct st_visual
*visual,
}
if (visual-depth_stencil_format != PIPE_FORMAT_NONE) {
- mode-haveDepthBuffer = GL_TRUE;
- mode-haveStencilBuffer = GL_TRUE;
-
mode-depthBits =
util_format_get_component_bits(visual-depth_stencil_format,
UTIL_FORMAT_COLORSPACE_ZS, 0);
mode-stencilBits =
util_format_get_component_bits(visual-depth_stencil_format,
UTIL_FORMAT_COLORSPACE_ZS, 1);
+
+ mode-haveDepthBuffer = mode-depthBits 0;
+ mode-haveStencilBuffer = mode-stencilBits 0;
}
if (visual-accum_format != PIPE_FORMAT_NONE) {
Looks good.
-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] [PATCH] Fix compile error caused by missing include dir
Johannes Obermayr wrote: Please apply this patch. Otherwise st:es has a compile error in st_es2.c! Thanks. Johannes Ping If you do not believe try compiling it on a fresh machine like OBS. Include flow: src/gallium/state_trackers/es/st_es2.c - src/mesa/state_tracker/st_manager.h - src/mesa/state_tracker/st_context.h - src/mesa/main/mtypes.h - src/mesa/main/glheader.h src/mesa/main/glheader.h cannot find: #include GL/gl.h #include GL/glext.h #include GL/internal/glcore.h With the patch it can ... And Mesa/Gallium should always be in a compilable state, shouldn't it? I'm committing the fix now. Sorry for the slow reply. -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] [PATCH] Export glXGPA symbols
tom fogal wrote: They seem to have become hidden with the visibility changes, at least --with-driver=xlib. Your patch doesn't apply cleanly for me but I'll do it by hand. It looks like there's some other functions also lacking PUBLIC. I'll fix those too. -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] [PATCH] dri: test whether the built drivers have unresolved symbols
On Fri, Mar 19, 2010 at 4:17 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Mar 19, 2010 at 10:39 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri l...@luca-barbieri.com wrote: Can we just put this program in the demos? Or at least just make it a separate target (make test-link)? It seems excessive to make this part of the default build path. The whole purpose is to run this as part of the standard build, so that the build fails if any driver is unloadable, (i.e. a modification to it was botched) and the tree hopefully doesn't get pushed to master. You can test it separately by just running glxinfo/glxgears, obviously. For developers that makes a lot of sense, but I've never seen any other projects impose this type of thing on regular users. You should only count the projects that allow by default successful build with undefined symbols (I have honestly no idea how common that is). This seems especially bad in mesa where there are many people working on core parts affecting all drivers and who cannot test easily all the drivers. At least a build failure to catch the obvious mistakes would be nice, though that will clearly not solve everything. And I think it is as profitable to the user, who do not use / know about LIBGL_DEBUG=verbose , and won't spot easily the dri failure and the fallback to software rendering. I'm OK with this change. If it causes hardship for anyone it could easily be reverted and revisited. -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] [PATCH] Re: master: undef/unmangled EGL functions are part of libOSMesa
Tom wrote: Ian Romanick i...@freedesktop.org writes: tom fogal wrote: $ 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. The trick here is that these are actually GL functions. Kristian added support for these a couple weeks ago, but probably didn't add mangling support. Regenerating gl_mangle.h was all that was needed. Thanks for the hint, I've committed the regenerated file. -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] [PATCH] Change some int64_t's to uint64_t's, to match CARD64's signedness
I'd like one of the other DRI developers to double-check this patch but the others look fine. I'll commit them soon. -Brian On Thu, Mar 11, 2010 at 9:13 PM, Jeff Smith whydo...@yahoo.com wrote: -- Download Intel® 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] [PATCH] dri/r700: Include shader/programopt.h instead of programopt.c.
Committed. Thanks. -Brian On Fri, Mar 12, 2010 at 12:38 AM, Luc Verhaegen l...@skynet.be wrote: Luc Verhaegen. -- 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] Framebuffers in mesa
On Fri, Mar 12, 2010 at 12:19 PM, Maciej Cencora m.cenc...@gmail.com wrote: Hi all, I've got some questions regarding FBOs in mesa. I hope you'll be able to answer at least some of them. GLcontext structure holds pointers to 4 gl_framebuffers (DrawBuffer, ReadBuffer, WinSysDrawBuffer, WinSysReadBuffer) and one to gl_renderbuffer (CurrentRenderbuffer). gl_framebuffer struct contains amongs other fields: _ColorDrawBuffers[], _ColorReadBuffers, _DepthBuffer, _StencilBuffer. Now having in mind that r300 wraps all gl_renderbuffers and gl_texture_object Do you mean that r300 subclasses gl_renderbuffer and gl_texture_object? That's what I think you mean. The term wrapping has a special meaning for renderbuffers (see below). (they contain HW buffer objects that I'm interested in), what is the proper way to get to read and draw buffers? The current read framebuffer is at ctx-ReadBuffer. The current drawing framebuffer is ctx-DrawBuffer. Then, if you're reading _colors_ the renderbuffer to use is ctx-ReadBuffer-_ColorReadBuffer. If you want to read _stencil_ values, it would be ctx-ReadBuffer-_StencilBuffer. Similarly for Z/depth, etc. To draw to color buffers (there may be more than one) you'll want ctx-DrawBuffer-_ColorDrawBuffers[]. For stencil it's ctx-DrawBuffer-_Stencil, etc. Renderbuffers typically correspond to a region of video memory. How that works is driver-dependent. What operations use ctx-_ReadBuffer besides glReadPixels,glCopyPixels and glCopyTex(Sub)Image? glCopyColorTable and maybe some other obscure functions. You got the main ones. What operations use ctx-_DrawBuffer besides rendering operations? (glBegin/glEnd, glDrawElements, glDrawArrays, ...) That's basically it, plus glClear. Am I correct that for ctx-_DrawBuffer field _ColorReadBuffer is unused, and for ctx-_ReadBuffer _ColorDrawBuffers is unused? No, they're used - see above. The _ColorReadBuffer field depends on the glReadBuffer() call. The _ColorDrawBuffers[] pointers depend on the glDrawBuffer() and glDrawBuffersARB() functions. It's important to understand the heirarchy of gl_framebuffers and gl_renderbuffers. Each framebuffer object has a collection of renderbuffers. Renderbuffers may also act as wrappers for gl_texture_object when doing render to texture. In this case, the renderbuffer acts as a 2D view into a level/slice/face of a texture object. Also, we have special depth/stencil renderbuffers which wrap combined depth/stencil buffers. See main/depthstencil.c That's mainly for software rendering, though. -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] Mesa (master): st/mesa: Always recalculate invalid index bounds.
The overriding goal is to avoid the expense of computing this in
software when the hardware can do the bounds check.
I guess we could add a PIPE_CAP query to ask the driver if it can do
bounds checking and if it can't, do it in the state tracker. But I
think Keith's interested in minimizing queries like this. Hence, try
to do it in the driver. I think it should be easy to write a
re-usable utility function to do the checks.
If you're seeing ~0, that means the Mesa VBO module has not computed
the bounds, and/or the user didn't provide them. I'd have to check the
code.
If vertex data is coming from regular memory and not a VBO we have no
idea what the legal bounds are.
-Brian
On Fri, Mar 12, 2010 at 5:06 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
This seems to be at odds with the idea that the pipe driver receives
pre-sanitized inputs.
If this patch is reverted:
- I can't trust the min and max elts, because they're set to ~0
- I can't just use the vertex buffer sizes, because they're set to ~0
So I have to do the maths myself, guessing just like st/mesa guesses. Maybe
this is specific to Radeons, but I *always* need those values.
I don't mind this, but IMO it *must* be doc'd, The minimum and maximum
index limits passed to draw_elements and draw_range_elements may be
invalid, and really, at that point, why are we even passing them? Seems
absurd to me. :3
Posting from a mobile, pardon my terseness. ~ C.
On Mar 12, 2010 5:40 AM, Keith Whitwell kei...@vmware.com wrote:
On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote:
Module: Mesa
Branch: master
Commit: 50876ddaaff72a324ac45e255985e0f84e108594
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
Author: Corbin Simpson mostawesomed...@gmail.com
Date: Fri Mar 12 02:51:40 2010 -0800
st/mesa: Always recalculate invalid index bounds.
These should always be sanitized before heading towards the pipe driver,
and if the calling function explicitly marked them as invalid, we need
to regenerate them.
Allows r300g to properly pass a bit more of Wine's d3d9 testing without
dropping stuff on the floor.
---
src/mesa/state_tracker/st_draw.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
b/src/mesa/state_tracker/st_draw.c
index 8b01272..d81b361 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
assert(ctx-NewState == 0x0);
/* Gallium probably doesn't want this in some cases. */
- if (!index_bounds_valid)
- if (!vbo_all_varyings_in_vbos(arrays))
- vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ if (index_bounds_valid != GL_TRUE) {
+ vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ }
Corbin,
This isn't really desirable. Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware. #
Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's. This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.
The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.
So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.
But maybe there is a better way to let the driver know that we are not
providing this information.
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
--
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] Cast needed in program_lexer.l ???
Karl Schultz wrote:
Am getting these warnings in the Windows build:
2Compiling...
2lex.yy.c
2program_lexer.l(327) : warning C4244: '=' : conversion from 'double'
to 'float', possible loss of data
2program_lexer.l(331) : warning C4244: '=' : conversion from 'double'
to 'float', possible loss of data
2program_lexer.l(335) : warning C4244: '=' : conversion from 'double'
to 'float', possible loss of data
2program_lexer.l(339) : warning C4244: '=' : conversion from 'double'
to 'float', possible loss of data
The corresponding lines in program_lexer.l are:
{num}?{frac}{exp}?{
yylval-real = _mesa_strtod(yytext, NULL);
return REAL;
}
{num}./[^.] {
yylval-real = _mesa_strtod(yytext, NULL);
return REAL;
}
{num}{exp}{
yylval-real = _mesa_strtod(yytext, NULL);
return REAL;
}
{num}.{exp} {
yylval-real = _mesa_strtod(yytext, NULL);
return REAL;
}
I think that we need to add a cast to these four places, e.g.:
yylval-real = (float) _mesa_strtod(yytext, NULL);
Changing progam_lexer.l requires that lex.yy.c (and others) be
regenerated with flex/bison and the generated files committed as well,
right? Is there a git trigger that does this, which would be really
cool? Or does someone need to run flex/bison manually and commit all
the resulting files?
If the latter, I don't know the exact process and I'd guess that someone
routinely does this.
If it is not a huge hassle, can someone add these casts to 7.8 and
master? The warnings are no big deal, but the casts do have some value
in documenting the implicit conversion.
I'll take care of it. It's up to the developer to regenerate the
files and commit them (to avoid everyone needing flex/bison).
-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] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
Luca Barbieri wrote: I've looked into the issue, and found a workaround by looking at what st_renderbuffer_alloc_storage (which is called to create the depth buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does. Adding: if(ctx) ctx-NewState |= _NEW_BUFFERS; at the end of st_set_framebuffer_surface seems to solve the warsow problem with no other regressions. Brian, is this the right fix? That's probably the right direction, but I think there's several other things to be fixed in st_set_framebuffer_surface(). I'll have a patch soon... -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] extensions supported or not in gallium
Roland Scheidegger wrote: Hi, there are currently a couple of extensions enabled in the mesa state tracker which probably shouldn't be. These were moved there by commit a0ae2ca033ec2024da1e01d1c11c0437837c031b (that is with dri they were already always enabled before). Someone knows off-hand which one we can enable or not? I'm going to kill off EXT_cull_vertex and TDFX_texture_compression_FXT1, clearly we can't handle them. The others in question are ARB_window_pos handled in core mesa. APPLE_client_storage should not be enabled by default. MESA_pack_invert handled by core mesa. NV_vertex_program NV_vertex_program1_1 (the latter two IIRC the problem was that regs needed to be zero-initialized) There may be other issues too. Someone would have to enable the extension(s) and do some testing. Currently gallium dri drivers also have ARB_imaging enabled too (via driInitExtensions()), I think that's not correct neither. Yeah, I think that needs to be disabled. -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] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
Brian Paul wrote:
Luca Barbieri wrote:
I've looked into the issue, and found a workaround by looking at what
st_renderbuffer_alloc_storage (which is called to create the depth
buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.
Adding:
if(ctx) ctx-NewState |= _NEW_BUFFERS;
at the end of st_set_framebuffer_surface seems to solve the warsow
problem with no other regressions.
Brian, is this the right fix?
That's probably the right direction, but I think there's several other
things to be fixed in st_set_framebuffer_surface(). I'll have a patch
soon...
OK, here's a patch which sets that flag, and:
1. always allocates the renderbuffer if it's not already present.
2. removes the framebuffer size update code. Core Mesa will do this
during state validation if _NEW_BUFFERS is set.
Please test. Thanks.
-Brian
diff --git a/src/mesa/state_tracker/st_framebuffer.c b/src/mesa/state_tracker/st_framebuffer.c
index 1d35e8d..cf8331f 100644
--- a/src/mesa/state_tracker/st_framebuffer.c
+++ b/src/mesa/state_tracker/st_framebuffer.c
@@ -167,9 +167,7 @@ st_set_framebuffer_surface(struct st_framebuffer *stfb,
uint surfIndex, struct pipe_surface *surf)
{
GET_CURRENT_CONTEXT(ctx);
- static const GLuint invalid_size = 999;
struct st_renderbuffer *strb;
- GLuint width, height, i;
/* sanity checks */
assert(ST_SURFACE_FRONT_LEFT == BUFFER_FRONT_LEFT);
@@ -183,18 +181,17 @@ st_set_framebuffer_surface(struct st_framebuffer *stfb,
strb = st_renderbuffer(stfb-Base.Attachment[surfIndex].Renderbuffer);
if (!strb) {
- if (surfIndex == ST_SURFACE_FRONT_LEFT) {
- /* Delayed creation when the window system supplies a fake front buffer */
- struct st_renderbuffer *strb_back
-= st_renderbuffer(stfb-Base.Attachment[ST_SURFACE_BACK_LEFT].Renderbuffer);
- struct gl_renderbuffer *rb
-= st_new_renderbuffer_fb(surf-format, strb_back-Base.NumSamples, FALSE);
- _mesa_add_renderbuffer(stfb-Base, BUFFER_FRONT_LEFT, rb);
- strb = st_renderbuffer(rb);
- } else {
- /* fail */
+ /* create new renderbuffer for this surface now */
+ const GLuint numSamples = stfb-Base.Visual.samples;
+ struct gl_renderbuffer *rb =
+ st_new_renderbuffer_fb(surf-format, numSamples, FALSE);
+ if (!rb) {
+ /* out of memory */
+ _mesa_warning(ctx, Out of memory allocating renderbuffer);
return;
}
+ _mesa_add_renderbuffer(stfb-Base, BUFFER_FRONT_LEFT, rb);
+ strb = st_renderbuffer(rb);
}
/* replace the renderbuffer's surface/texture pointers */
@@ -206,39 +203,16 @@ st_set_framebuffer_surface(struct st_framebuffer *stfb,
* But when we do, we need to start setting this dirty bit
* to ensure the renderbuffer attachements are up-to-date
* via update_framebuffer.
+ * Core Mesa's state validation will update the parent framebuffer's
+ * size info, etc.
*/
ctx-st-dirty.st |= ST_NEW_FRAMEBUFFER;
+ ctx-NewState |= _NEW_BUFFERS;
}
/* update renderbuffer's width/height */
strb-Base.Width = surf-width;
strb-Base.Height = surf-height;
-
- /* Try to update the framebuffer's width/height from the renderbuffer
-* sizes. Before we start drawing, all the rbs _should_ be the same size.
-*/
- width = height = invalid_size;
- for (i = 0; i BUFFER_COUNT; i++) {
- if (stfb-Base.Attachment[i].Renderbuffer) {
- if (width == invalid_size) {
-width = stfb-Base.Attachment[i].Renderbuffer-Width;
-height = stfb-Base.Attachment[i].Renderbuffer-Height;
- }
- else if (width != stfb-Base.Attachment[i].Renderbuffer-Width ||
- height != stfb-Base.Attachment[i].Renderbuffer-Height) {
-/* inconsistant renderbuffer sizes, bail out */
-return;
- }
- }
- }
-
- if (width != invalid_size) {
- /* OK, the renderbuffers are of a consistant size, so update the
- * parent framebuffer's size.
- */
- stfb-Base.Width = width;
- stfb-Base.Height = height;
- }
}
--
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] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
Luca Barbieri wrote: Solves the Warsow issue and seems to work. OK, I think you can commit the patch to 7.8 then. -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] Broken variable scopes in Mesa?
Mathias Gottschlag wrote:
While trying Horde3D on nouveau I found out that Mesa rejects the
following shader which correctly compiles on the proprietary drivers
and, as far as I can see, seems to be correct according to the GLSL specs:
uniform sampler2D tex;
void main()
{
vec3 tex = texture2D(tex, gl_TexCoord[0].st);
gl_FragColor.rgb = tex;
}
Here Mesa chokes on the first parameter to texture2D because it inserts
an (undefined?) vec3 there, the same way as C/C++ would react here,
which results in the following error:
Error: undefined function 'texture2D'
Error: incompatible types in assignment
The GLSL spec (1.20) however says:
Within a declaration, the scope of a name starts immediately after the
initializer if present or immediately
after the name being declared if not.
Did I miss something here, did I interpret the specs wrong? I looked
into the sources in order to maybe fix the problem, but without any
knowledge of Mesa's internals, that's a bit to high for me.
It's probably incorrect in our compiler.
You're best off playing it safe and using another variable name. I
wouldn't be surprised if other GLSL compilers got this wrong too.
-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] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
Michel Dänzer wrote: On Thu, 2010-03-11 at 11:28 -0700, Brian Paul wrote: Luca Barbieri wrote: Solves the Warsow issue and seems to work. OK, I think you can commit the patch to 7.8 then. Can this also be backported to mesa_7_7_branch? Sure, if you can test it. We might want to wait a few days and make sure nothing regresses with it on the 7.8 branch. I'll commit it there. -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] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
Luca Barbieri wrote: Shouldn't _mesa_add_renderbuffer(stfb-Base, BUFFER_FRONT_LEFT, rb); be _mesa_add_renderbuffer(stfb-Base, surfIndex, rb); instead, since you seem to make the on-demand creation mechanism generic and no longer limited to the front buffer? Yes. Fixed now. -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] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]
Keith Whitwell wrote: On Wed, 2010-03-10 at 06:47 -0800, Corbin Simpson wrote: I don't know the VBO code that well, so I'm asking you guys if this has ever come up before. http://bugs.winehq.org/show_bug.cgi?id=22000 Gallium and indexed rendering are not very happy with each other. I get some fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from Mesa git. My current guess, based on the Mesa debug info I dumped, is that the indexed rendering code is slightly baked and maybe trusting the underlying GL driver a bit too much. get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start (nil) end 0xfffc attr 1: stride 16 size 4 start 0xc end (nil) buffer range: (nil) 0xfffc range -4 max index 4294967295 Can you post the patch you used to print this info, Corbin? So right here (from device.ok) we have interleaved userspace VBO, that is being prepped inside core Mesa. Two delightful things here; the first attr seems way off-base, it shouldn't dare be giving us bad pointers, and the second attr's pointers don't even line up! In VBO rendering, the pointers are really just offsets into the VBO, so should be interpreted as numbers. The first attribute has what looks like a small negative number. I don't know if that's legal or not in GL - I suspect it is probably not legal and should be rejected in the mesa validation code. This would have come in via the 'ptr' argument to one of the glVertex/Color/etcPointer() functions. We never check for negative pointer values. I suspect what is happening is wine is passing in some negative values and we aren't properly rejecting them in mesa. Compare to a sane program (Mesa's drawarrays): get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start 0x8087020 end 0x808705c attr 1: stride 16 size 4 start 0x808702c end 0x8087060 buffer range: 0x8087020 0x8087060 range 64 max index 3 This doesn't look like VBO rendering though. These are regular vertex arrays, meaning these values are proper pointers. r300g doesn't really care. It shouldn't have to - the expectation in gallium is that inputs have been validated. The kernel drops the rendering on the floor for a variety of reasons, not least being the ridiculous max_index. But then it segfaults, and I have zero idea why. I'd guess it's something to do with tossing around NULL pointers like candy, but I'm honestly not sure and I haven't really dug into the DLL code yet. It's great you found a bug, but why all the excitement? Just track it down and propose a fix. Mesa's pretty well debugged, but there are always going to be new issues. I'm not sure why it warrants this type of implicit criticism when you come across something new. -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] Piglit fbo tests
Brian Paul wrote: Maciej Cencora wrote: Hi, following 3 piglit tests are failing on r300 because they're trying to use GL_ARB_texture_non_power_of_two without checking if this extension is available: fbo-blit fbo-nodepth-test fbo-nostencil-test I'm not sure what solution is preferable, 1) change the teximage sizes to be POT, 2) require ARB_texture_npot. I've tried first solution for fbo-blit but it segfaults, trying to execute function at null address, so it would require some more investigation. We should use POT texture sizes so that the test always does _something_. I've fixed the fbo-blit test to use a POT texture. Maybe you can fix the other tests similarly. BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some other bugs I've recently found... -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] Piglit fbo tests
Maciej Cencora wrote: Dnia środa, 10 marca 2010 o 19:17:25 Maciej Cencora napisał(a): Dnia środa, 10 marca 2010 o 16:36:01 Brian Paul napisał(a): Brian Paul wrote: Maciej Cencora wrote: Hi, following 3 piglit tests are failing on r300 because they're trying to use GL_ARB_texture_non_power_of_two without checking if this extension is available: fbo-blit fbo-nodepth-test fbo-nostencil-test I'm not sure what solution is preferable, 1) change the teximage sizes to be POT, 2) require ARB_texture_npot. I've tried first solution for fbo-blit but it segfaults, trying to execute function at null address, so it would require some more investigation. We should use POT texture sizes so that the test always does _something_. I've fixed the fbo-blit test to use a POT texture. Maybe you can fix the other tests similarly. BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some other bugs I've recently found... -Brian Sure, I'll look into it. Regards, Maciej It looks like you've forgotten to remove the ARB_npot check for fbo-blit. Fixed. After removing it the tests segfaults. #0 0x in ?? () #1 0x0042cfac in run_test () #2 0x0042d1f3 in piglit_display () #3 0x0042e639 in display () #4 0x77682ddf in processWindowWorkList (window=0x673a90) at glut_event.c:1306 #5 0x77682ef9 in __glutProcessWindowWorkLists () at glut_event.c:1356 #6 0x77682f6f in glutMainLoop () at glut_event.c:1377 #7 0x0042e7b1 in main () Unfortunately I don't know how to build the piglit tests with debugging symbols to investigate it further. Run ccmake . and change CMAKE_BUILD_TYPE to Debug. -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] Commit messages broken??
Brian Paul wrote: Keith Whitwell wrote: I haven't seen any of these for a while now... Anyone have any ideas? I haven't seen them either. I don't know what's going on, but Tollef Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday (though Michel and I haven't move the subscriber lists yet). Perhaps something broke from that? Tollef? It looks like the list itself is OK but the git trigger to send out the commit messages isn't working. Do any git experts know what might be wrong? -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] Piglit fbo tests
Maciej Cencora wrote: Dnia środa, 10 marca 2010 o 19:35:48 Brian Paul napisał(a): Maciej Cencora wrote: Dnia środa, 10 marca 2010 o 19:17:25 Maciej Cencora napisał(a): Dnia środa, 10 marca 2010 o 16:36:01 Brian Paul napisał(a): Brian Paul wrote: Maciej Cencora wrote: Hi, following 3 piglit tests are failing on r300 because they're trying to use GL_ARB_texture_non_power_of_two without checking if this extension is available: fbo-blit fbo-nodepth-test fbo-nostencil-test I'm not sure what solution is preferable, 1) change the teximage sizes to be POT, 2) require ARB_texture_npot. I've tried first solution for fbo-blit but it segfaults, trying to execute function at null address, so it would require some more investigation. We should use POT texture sizes so that the test always does _something_. I've fixed the fbo-blit test to use a POT texture. Maybe you can fix the other tests similarly. BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some other bugs I've recently found... -Brian Sure, I'll look into it. Regards, Maciej It looks like you've forgotten to remove the ARB_npot check for fbo-blit. Fixed. After removing it the tests segfaults. #0 0x in ?? () #1 0x0042cfac in run_test () #2 0x0042d1f3 in piglit_display () #3 0x0042e639 in display () #4 0x77682ddf in processWindowWorkList (window=0x673a90) at glut_event.c:1306 #5 0x77682ef9 in __glutProcessWindowWorkLists () at glut_event.c:1356 #6 0x77682f6f in glutMainLoop () at glut_event.c:1377 #7 0x0042e7b1 in main () Unfortunately I don't know how to build the piglit tests with debugging symbols to investigate it further. Run ccmake . and change CMAKE_BUILD_TYPE to Debug. -Brian I'm sending fixes for fbo-blit and fbo-no-depth/stencil-test tests. Committed. 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] Commit messages broken??
Zack Rusin wrote: On Wednesday 10 March 2010 15:18:03 Zack Rusin wrote: On Wednesday 10 March 2010 14:59:42 Zack Rusin wrote: Maybe /usr/bin/mail is broken, I'll double check it. Yea, that's it. Someone installed a new mail daemon on the server. We're using -a to specify the Content-Type header in mails, but the heirloom mailx that has been installed uses the -a option to specify attachments and since filename Content-Type: text/plain; is not a valid filename it exits with an error. I'll try to fix it right now. k, it should be working now. I switched it to use sendmail directly so that future changes to /usr/bin/mail don't affect it. Thanks, Zack!! -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] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
Mesa/master is correct as is. Changing ST_SURFACE_DEPTH to be != BUFFER_DEPTH is just hiding another problem elsewhere. If ST_SURFACE_DEPTH==8 then calling st_set_framebuffer_surface(fb, ST_SURFACE_DEPTH, surf) is effectively setting the fb's COLOR0 attachment to be a Z/stencil buffer (and leaves the fb's DEPTH attachment undefined (or set to a default surface)). I'm surprised that doesn't cause tons of problems elsewhere. To debug this, I'd start by looking for calls to st_set_framebuffer_surface() with surfIndex==ST_SURFACE_DEPTH, then no-op those calls. That's roughly what would be happening if ST_SURFACE_DEPTH==8. -Brian On Wed, Mar 10, 2010 at 6:33 PM, Marek Olšák mar...@gmail.com wrote: I second that. The commit breaks 6 glean tests (api2, clipFlat, fragProg1, occluQry, pointAtten, texCombine4) with r300g. -Marek On Wed, Mar 10, 2010 at 10:50 PM, Luca Barbieri l...@luca-barbieri.com wrote: In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd. How about cherry-picking that commit into master, until a fix for the bugs the revert commit introduces are found? The reverted commit currently breaks the Warsow main menu for me, making it show garbage. -- 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 -- 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] gallium-sw-api-2, cell driver alert!
Brian Paul wrote: Keith Whitwell wrote: This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. My PS3 is still going- I'll look into it. OK, it compiles but it doesn't run at all. The SPUs immediately crash because of invalid commands in the batch buffers. I suspect there's other breakage in texture handing and displaying of display targets. I don't have time to fix this so I guess cell will stay broken for a while. -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] gallium-sw-api-2, cell driver alert!
Keith Whitwell wrote: This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. My PS3 is still going- I'll look into it. -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] Commit messages broken??
Keith Whitwell wrote: I haven't seen any of these for a while now... Anyone have any ideas? I haven't seen them either. I don't know what's going on, but Tollef Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday (though Michel and I haven't move the subscriber lists yet). Perhaps something broke from that? Tollef? -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] Piglit fbo tests
Maciej Cencora wrote: Hi, following 3 piglit tests are failing on r300 because they're trying to use GL_ARB_texture_non_power_of_two without checking if this extension is available: fbo-blit fbo-nodepth-test fbo-nostencil-test I'm not sure what solution is preferable, 1) change the teximage sizes to be POT, 2) require ARB_texture_npot. I've tried first solution for fbo-blit but it segfaults, trying to execute function at null address, so it would require some more investigation. We should use POT texture sizes so that the test always does _something_. Where's the crash? -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] [rfc] to SpanRenderStart to avoid texture mapping overheads
Keith Whitwell wrote: On Sat, 2010-03-06 at 00:30 -0800, Dave Airlie wrote: So in classic drivers we can hit swrast fallbacks for things like ReadPixels where we know we aren't going to have to want to touch textures at all. This would be useful for the r300 driver where Maciej is working on texture tiling will allow us to avoid the untiling overheads that mapping textures requires for most sw fallbacks. There may be other operations where we can do this also. For render to texture scenarios the driver should still map the textures via the FBOs anyways. Dave. Looks like a reasonable idea to me. Looks good to me too, Dave. This reminds me that I have a branch that cleans up some of the fb/texture map/unmap code in Mesa. I need to get back on that one of these days... -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] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
Looks OK, but have you tested with Glean's clipFlat test? If it passes go ahead and commit. -Brian Marek Olšák wrote: The attached patches change softpipe and llvmpipe so that they never provoke the first vertex for quads. Please review. I think that these and the Corbin's one could be pushed by now, couldn't they? -Marek On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul bri...@vmware.com mailto:bri...@vmware.com wrote: Corbin Simpson wrote: From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com mailto:mostawesomed...@gmail.com Date: Wed, 10 Feb 2010 10:39:18 -0800 Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex. Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out how to test it in this new API world. :T --- src/mesa/state_tracker/st_extensions.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index d5f5854..e2d871b 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st) /* XXX separate query for early function return? */ st-ctx-Shader.EmitContReturn = screen-get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED); + + /* Quads always follow GL provoking rules. */ + c-QuadsFollowProvokingVertexConvention = GL_FALSE; } This causes the glean clipFlat test to fail with softpipe. The gallium softpipe driver _does_ implement the quad follows provoking vertex convention. I don't have time right now to update the softpipe driver so this patch will have to wait a while. Maybe someone else can look at it sooner. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net mailto: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
[Mesa3d-dev] [RFC] Minor gallium changes
1. Rename pipe_sampler_state:min_mip_filter to mip_filter. I don't know that the min part of that field refers to. 2. Remove PIPE_MAX_TEXTURE_LEVELS from p_state.h This token isn't used anywhere in the gallium interface anymore, nor the state trackers. I've already removed the use of this token in the gallium drivers (use per-driver #defines instead). There's still some use in the blitter code though. 3. BTW, none of these #defines are used in the gallium interface header files: PIPE_MAX_CONSTANT_BUFFERS PIPE_MAX_ATTRIBS PIPE_MAX_SAMPLERS PIPE_MAX_VERTEX_SAMPLERS They are used in the utility code and drivers though. Should we define these in the gallium interface if they're not used by the interface itself? -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] Mesa (master): util: Code generate functions to pack and unpack a single pixel.
On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
Author: José Fonseca jfons...@vmware.com
Date: Fri Feb 26 16:45:22 2010 +
util: Code generate functions to pack and unpack a single pixel.
Should work correctly for all pixel formats except SRGB formats.
Generated code made much simpler by defining the pixel format as
a C structure. For example this is the generated structure for
PIPE_FORMAT_B6UG5SR5S_NORM:
union util_format_b6ug5sr5s_norm {
uint16_t value;
struct {
int r:5;
int g:5;
unsigned b:6;
} chan;
};
José, are you aware that the memory layout of bitfields is mostly
implementation dependent? IME this makes them mostly unusable for
modelling hardware in a portable manner.
It's not only implementation dependent and slow -- it is also buggy!
gcc-4.4.3 is doing something very fishy to single bit fields.
See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
fine.
Am I missing something or is this effectively a bug?
Same result with gcc 4.4.1.
If pixel.chan.a is put into a temporary int var followed by the
scaling arithmetic it comes out as expected. Looks like a bug to me.
BTW, it looks like sizeof(union util_format_b5g5r5a1_unorm) == 4, not 2.
-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] APPLE_object_purgeable, ready for inclusion!
Chris Wilson wrote: Thanks to Intel QA providing a few piglit cases to test the API, this has had a cursory test and identified the silly cases of using the wrong lookup functions. The ugly part is that I've used 3 different driver functions to handle each of the 3 object variants - the alternative would be pass in a void pointer and a type id. If we acquire more distinct object types, then multiplexing a single driver function would be preferable to adding multiple stubs. Please review and include in 7.7! :) This will go into Mesa 7.8, actually. I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches misnumbered or did 2/4 not get posted? Can you commit these, Chris? Are the new piglit tests going into the fd.o repository? I don't see them yet. -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] APPLE_object_purgeable, ready for inclusion!
Chris Wilson wrote: On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul bri...@vmware.com wrote: Chris Wilson wrote: Please review and include in 7.7! :) This will go into Mesa 7.8, actually. I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches misnumbered or did 2/4 not get posted? As Michael pointed out, the changes to the autogenerated files were rather large. Can you commit these, Chris? Ok, pushed to master. Thanks. Thanks, Chris. I'm just going to make some minor clean-ups in bufferobj.c (not just your code). -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] Mesa (master): mesa: Fix unsigned comparison.
Michel Dänzer wrote:
On Thu, 2010-03-04 at 02:00 -0800, Vinson Lee wrote:
Michel, thanks for spotting this.
I've reverted the bad commit. Please go ahead and submit your correct fix.
Actually, I wonder if something like the below isn't needed to avoid any
undesired effects from integer overflows.
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 326ad6f..8460265 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -130,6 +130,7 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum
type,
struct _mesa_prim prim;
struct _mesa_index_buffer ib;
GLuint min, max;
+ GLint64 min64, max64;
/* Only the X Server needs to do this -- otherwise, accessing outside
* array/BO bounds allows application termination.
@@ -146,9 +147,12 @@ check_index_bounds(GLcontext *ctx, GLsizei count, GLenum
type,
ib.obj = ctx-Array.ElementArrayBufferObj;
vbo_get_minmax_index(ctx, prim, ib, min, max);
+ min64 = min;
+ min64 += basevertex;
+ max64 = max;
+ max64 += basevertex;
- if (min + basevertex 0 ||
- max + basevertex ctx-Array.ArrayObj-_MaxElement) {
+ if (min64 0 || max64 ctx-Array.ArrayObj-_MaxElement) {
/* the max element is out of bounds of one or more enabled arrays */
_mesa_warning(ctx, glDrawElements() index=%u is
out of bounds (max=%u), max,
ctx-Array.ArrayObj-_MaxElement);
I'd be happy with a simple cast for now. One of these days we'll need
to be concerned with 4GB buffers (or 2GB buffers and signed
arithmetic) but we're not quite there yet. There'd probably be other
issues to fix. The buffer object code will need to be audited.
Generally, when fixing signed / unsigned comparison warnings I cast
the unsigned value to signed, Vinson.
-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] Move lists to freedesktop.org?
Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? -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] Mesa (master): mesa: Remove pointless comparison of unsigned integer with a negative constant.
Vinson Lee wrote:
-Original Message-
mesa: Remove pointless comparison of unsigned integer with a negative
constant.
---
src/mesa/shader/prog_execute.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/mesa/shader/prog_execute.c
b/src/mesa/shader/prog_execute.c
index aea4b07..ee422e7 100644
--- a/src/mesa/shader/prog_execute.c
+++ b/src/mesa/shader/prog_execute.c
@@ -1780,15 +1780,10 @@ _mesa_execute_program(GLcontext * ctx,
break;
case OPCODE_PRINT:
{
-if (inst-SrcReg[0].File != -1) {
- GLfloat a[4];
- fetch_vector4(inst-SrcReg[0], machine, a);
- _mesa_printf(%s%g, %g, %g, %g\n, (const char *) inst-
Data,
-a[0], a[1], a[2], a[3]);
-}
-else {
- _mesa_printf(%s\n, (const char *) inst-Data);
-}
+GLfloat a[4];
+fetch_vector4(inst-SrcReg[0], machine, a);
+_mesa_printf(%s%g, %g, %g, %g\n, (const char *) inst-
Data,
+ a[0], a[1], a[2], a[3]);
I don't think this is correct. The shader assembler used to set the
register file to -1 to note the difference between the following two
instructions:
PRINT Hello, world;
PRINT vertex color, color;
Even if comparing with -1 isn't entirely correct, removing the code
altogether is clearly wrong.
}
break;
case OPCODE_END:
Where is the set of the register file to -1?
At nvvertparse.c:1099 it's set to zero. I don't see where it's set to
-1 either.
Should the -1 comparison been against PROGRAM_FILE_MAX or PROGRAM_UNDEFINED
instead?
The assignment above should probably use PROGRAM_UNDEFINED instead of 0.
-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] Remove support for GCC version 3.3.x
On Mon, Mar 1, 2010 at 4:19 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There are a few places in Mesa where we check the GCC version and have alternate code paths. It looks like almost all of the checks go away if we require GCC version of at least 3.3.0. The last 3.2 (or earlier) release was in April of 2003. It seems safe to remove support for a 7 year old version. Opinions? Sounds OK. It could always be reverted if necessary. -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] Remove color index rendering?
On Fri, Feb 26, 2010 at 7:19 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: While we're on the topic of removing dead weight, can we remove support for color index rendering? None of the hardware drivers support color index rendering, and color index rendering is deprecated in OpenGL 3.0 (and removed in 3.1). Can it please die in a fire? I have just pushed a branch that removes color-index rendering. It is available for review in the remove_ci_rendering branch of git://anongit.freedesktop.org/~idr/mesa.git. I have done on minimal testing so far, but I intend to do more over the weekend. It took most of the week just to get all the changes made. There are 38 individual patches. The patches remove a total of 2,304 lines of code. I tried to make it easier to review by keeping the individual changes small. There are probably some additional changes that could be made. There is still a bit of index tracking in TNL and other related places. I think some of this can be removed. Such removals would be more invasive (grep for MAT_*_INDEX), I think you mean the MAT_INDEX_* tokens there. We can weed out some of that little stuff over time. and may impact our adherence to the spec. For example, some queries would return incorrect values. In any case, I'm satisfied with this set of removals for now. The branch looks good. Just one minor thing: please document CI removal in the 7.8 release notes file. -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] Patch to fix -m32 for progs/glsl
Török Edvin wrote: Hi, I had to apply the following patch to build mesa as 32-bit, on a 64-bit Debian system (so that wine, and all else get proper 3D accelereration with the new r600 driver). progs/glsl is built by default, but it was not using -m32. Please apply the patch to mesa git master, it is a one-line makefile fix. Committed. 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] move normalized texel coordinates bit to sampler view
Roland Scheidegger wrote: On 25.02.2010 18:39, michal wrote: Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? But we don't have rect targets in gallium hence we need the flag. I think conceptually this makes sense since for texture layouts etc. drivers won't care one bit if this is 2d npot or rect texture. Though I guess introducing rect targets instead would be another option. We should also be thinking about texture array targets. With a 2D texture array, the S and T coords would be normalized, but not R. I think we either need new texture targets for RECT, 1D_ARRAY, 2D_ARRAY, etc. or per-dimension normalization flags. I'm thinking the former may be better (simpler) since textures are created as a particular type and not changed afterward. We also know the texture type/target when we execute TEX shader instructions. If it's part of sampler state it gives the impression that it's variable state, but it really isn't. -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] Mesa removals
Kristian Høgsberg wrote: On Mon, Feb 22, 2010 at 11:38 AM, Brian Paul bri...@vmware.com wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? This was posted four days ago and I didn't hear any objections, only some nostalgia background noise. I've removed all the drivers and subdirectories mentioned above and posted the result in the mesa-cleanup branch in git://anongit.freedesktop.org/~krh/mesa Brian, if that looks ok to you, I can push that to the main mesa repo now It looks like progs/windml/ wasn't completely removed. Looks good otherwise. 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] [PATCH] glapi cleanup: swap dispatch.[ch]
On Tue, Feb 23, 2010 at 9:38 PM, Chia-I Wu olva...@gmail.com wrote: This patch series moves src/mesa/dispatch.c to src/glapi/glapi_dispatch.c and src/glapi/dispatch.h to src/mesa/dispatch.h. As can be seen in sources.mak, dispatch.c is actually a glapi source file. And although not mentioned anywhere, dispatch.h is a core Mesa header file. It honors IN_DRI_DRIVER and should not be used outside core Mesa. Another benefit of this clean up is that it is now clear that IN_DRI_DRIVER is not used elsewhere except for in core Mesa. I didn't test, but sounds good to me. -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] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output
On Sun, Feb 21, 2010 at 3:33 PM, Keith Packard kei...@keithp.com wrote: The bash 'cd' command tends to emit random stuff to stdout when the CDPATH variable is set, so clear it to keep extra filenames from being emitted from the expand_archive function, which would otherwise cause mklib to fail. Signed-off-by: Keith Packard kei...@keithp.com Signed-off-by: Brian Paul bri...@vmware.com Please commit to both master and mesa_7_7_branch. 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] [PATCH] bin/mklib: Clear CDPATH to avoid damaging expand_archive output
On Sun, Feb 21, 2010 at 5:54 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Sun, Feb 21, 2010 at 2:33 PM, Keith Packard kei...@keithp.com wrote: The bash 'cd' command tends to emit random stuff to stdout when the CDPATH variable is set, so clear it to keep extra filenames from being emitted from the expand_archive function, which would otherwise cause mklib to fail. Signed-off-by: Keith Packard kei...@keithp.com Congratulations on wading in to mklib, it's not a friendly place. :) Heh, I guess you've never had to debug libtool then. mklib is a walk in the park by comparison. -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] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default
On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, the attached patch modifies st/dri to not enable EXT_draw_buffers2 by default because r300g and most probably even some other drivers can't support this extension. The drivers reporting support of PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch. Please review. Hmm, I believe the extensions listed in dri_extensions.c are those that _may_ be supported by drivers. But its the st_extensions.c code that queries the driver for various caps (such as PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if applicable. Is GL_EXT_draw_buffers2 really being advertised by glxinfo with r300g? -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] Remove color index rendering?
On Fri, Feb 19, 2010 at 5:16 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While we're on the topic of removing dead weight, can we remove support for color index rendering? None of the hardware drivers support color index rendering, and color index rendering is deprecated in OpenGL 3.0 (and removed in 3.1). Can it please die in a fire? I think it can probably go. I haven't tested CI mode rendering in many years. Who knows if it even works any more. -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] glxinfo -l ARB prog errors
On Sat, Feb 20, 2010 at 9:32 AM, Xavier Chantry chantry.xav...@gmail.com wrote: On Sat, Feb 20, 2010 at 5:22 PM, Brian Paul brian.e.p...@gmail.com wrote: On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry chantry.xav...@gmail.com wrote: It seems the commit below will always report an user error when glxinfo -l is called. And indeed I always get the following : $ glxinfo -l ... GL_VERTEX_PROGRAM_ARB: ... Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Should glxinfo be fixed to avoid this error ? We could just put the fragment program only parameter in its own list, and not use them when target is vertex program. Well, normally GL errors aren't reported to stderr so most people running non-debug builds won't see those. But yeah, we probably shouldn't generate the errors anyway. Feel free to write a patch to glxinfo... I only realized yesterday that non-debug was the reason other people (and some of my systems) didn't show these errors. It had been bugging me for a while :) Attached patch should fix it. Thanks. I'll commit it soon. -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
[Mesa3d-dev] Mesa removals
Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? -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] Mesa removals
Corbin wrote: Glide is a GL-glide driver, right? So it is not needed for libglide apps? Yes, correct. -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] [PATCH 00/11] Kill various _mesa_* wrappers.
On Sat, Feb 20, 2010 at 3:21 AM, Olivier Galibert galib...@pobox.com wrote: On Fri, Feb 19, 2010 at 11:30:44AM -0800, Ian Romanick wrote: I'd also like to see additional patches to eliminate: - _mesa_bzero - Conditionally wrap this if HAVE_BZERO is not defined. Do the usual autoconf magic to detect it. Let non-autoconf builds figure it out there own way. Shouldn't you just use memset instead? Yes, already done. -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] [PATCH] Remove a few more instances of the MEMCPY macro.
On Fri, Feb 19, 2010 at 1:50 PM, Kenneth Graunke kenn...@whitecape.org wrote: --- It looks like these were missed in commit 2240ba10. This also removes the last of the SUNOS4 defines; we can probably remove configs/sunos4* as well. src/glu/mesa/gluP.h | 10 -- src/glu/mesa/nurbssrf.c | 4 ++-- src/glu/mesa/project.c | 2 +- src/glu/mini/gluP.h | 10 -- src/glu/mini/project.c | 2 +- 5 files changed, 4 insertions(+), 24 deletions(-) Actually, I'd like to add src/glu/mesa and src/glu/mini to the list of things to remove from Mesa entirely. Does anyone still have any interest in these? -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] glxinfo -l ARB prog errors
On Fri, Feb 19, 2010 at 7:34 PM, Xavier Chantry chantry.xav...@gmail.com wrote: It seems the commit below will always report an user error when glxinfo -l is called. And indeed I always get the following : $ glxinfo -l ... GL_VERTEX_PROGRAM_ARB: ... Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname) Should glxinfo be fixed to avoid this error ? We could just put the fragment program only parameter in its own list, and not use them when target is vertex program. Well, normally GL errors aren't reported to stderr so most people running non-debug builds won't see those. But yeah, we probably shouldn't generate the errors anyway. Feel free to write a patch to glxinfo... -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] Mesa release for the end of March?
On Thu, Feb 18, 2010 at 9:50 PM, Chia-I Wu olva...@gmail.com wrote: On Fri, Feb 19, 2010 at 8:25 AM, Brian Paul bri...@vmware.com wrote: Assuming this plan still works for people, I'll make the mesa_7_8_branch on Friday, February 26th. I think we could get by with a shorter beta period. There's a few more things that would be nice to do for 7.8 which I doubt I'd get to before the 26th: 1. GL_APPLE_object_purgeable - I think the last round of patches looked OK. Chris? 2. _mesa_memcpy() - memcpy(), etc. replacement. There were patches for this that haven't been applied yet. Maybe someone could pick those up. 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx, allegro, ggi, dri/mga, dri/mach64. Maybe more. Any objections? I like this change. There are some Makefiles under src/mesa/main/. Are they still used? Could we remove them? You can remove them. -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] Mesa release for the end of March?
On Fri, Feb 19, 2010 at 10:59 AM, José Fonseca jfons...@vmware.com wrote: On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: 2010/2/19 Brian Paul brian.e.p...@gmail.com: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: I applied the patches from Kenneth Graunke on the list for this. Can we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and _mesa_bzero() too? I've remove _mesa_bzero() just now, plus some other macro wrappers. We might as well remove the malloc/calloc() wrappers too, but that'll be a bit more work. I'm using: git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g which does most of the work. I'll do the same thing for _mesa_calloc and _mesa_free, review the result and commit that. All done. I was looking at the MALLOC, CALLOC, MALLOC_STRUCT, CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the _mesa_align_* functions. Do we want to drop those too? Given that we'll unify these for gallium and mesa it's better leave them allone for now -- it will make it easier to search'n'replace when we do that. I hope to get started on this task next week. OK, disregard my other reply then. I forgot about this, Jose. -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] Mesa release for the end of March?
2010/2/19 Kristian Høgsberg k...@bitplanet.net: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: 2010/2/19 Brian Paul brian.e.p...@gmail.com: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: I applied the patches from Kenneth Graunke on the list for this. Can we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and _mesa_bzero() too? I've remove _mesa_bzero() just now, plus some other macro wrappers. We might as well remove the malloc/calloc() wrappers too, but that'll be a bit more work. I'm using: git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g which does most of the work. I'll do the same thing for _mesa_calloc and _mesa_free, review the result and commit that. All done. I was looking at the MALLOC, CALLOC, MALLOC_STRUCT, CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the _mesa_align_* functions. Do we want to drop those too? I hesitated because src/gallium/README.portability says Use MALLOC, CALLOC, FREE instead of the malloc, calloc, free functions. But as far as I can see, they're not redefined or anything for gallium and they just resolve to the standard malloc, calloc and free functions. Am I missing something? Let's keep the Gallium code as-is. But for Mesa: MALLOC_STRUCT and CALLOC_STRUCT should be kept. They save a lot of typing. MALLOC, CALLOC, and FREE can go. The ALIGN macros could probably go too (just call the align functions). Years ago, some systems defined malloc() as returning char * instead of void * so the Mesa wrappers helped with casting. Plus, back before valgrind I'd often rig up my own malloc-debug code to track down memory errors. The macros were handy for that. -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] Mesa release for the end of March?
Guillem Jover wrote: Hi! [ CCing Daniel Borca who used to work on 3dfx support in Mesa and libglide, not sure though if he is around or interested anymore. ] On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote: 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx, allegro, ggi, dri/mga, dri/mach64. Maybe more. Any objections? Could the drivers for actual hardware (namely glide, tdfx, dri/mga and dri/mach64) be exempted from removal? I at least still have cards for those, not sure though how many users might be out there, but whenever libglide has broken in Debian, I tend to receive bug reports, so I'd assume there's still some. And it always saddens me a bit when hardware support gets dropped in projects. I have/had no idea if the tdfx, glide, mga or mach64 drivers function anymore. If someone is actively using or testing the drivers I guess we could keep them, but I'd rather not otherwise. Out of curiousity, are those burdersome to deal with, or hindering further imrpovements or development in other areas? Anything major that needs to be done to them? I can perfectly understand the desire to remove legacy stuff that might block or take much of your time, keeping them would still be appreciated. I also fear I have my hands full already with lots of stuff, so cannot offer much of help, at least right now. Though, I should finally cleanup and commit upstream some of the libglide patches I have in Debian. When I change core things in Mesa (like the texformat overhaul last fall) I wonder if the lesser-used drivers still function since I don't test them. In any case, older versions of Mesa with the drivers in question won't go away so people can use those if needed. -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] Mesa release for the end of March?
tom fogal wrote: Ian Romanick i...@freedesktop.org writes: Since we're not using CVS, would it be possible to start naming the release branches with just the release version? Likewise for release tags? Specifically, I'm proposing to use 7.8 for this next branch and 7.8.0 for the release tag. +1. It's a pain to type out the full name all the time ;) I like keeping things consistent but this change would be OK. -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] [PATCH 08/12] intel: Implement DRI image extension
Kristian Høgsberg wrote:
2010/2/12 Ian Romanick i...@freedesktop.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index f7ce87e..c2c8c6e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -41,6 +41,7 @@
#include intel_fbo.h
#include intel_screen.h
#include intel_tex.h
+#include intel_regions.h
#include i915_drm.h
@@ -141,11 +142,84 @@ static const struct __DRI2flushExtensionRec
intelFlushExtension = {
intelDRI2FlushInvalidate,
};
+static __DRIimage *
+intel_create_image_internal(__DRIcontext *context,
+ int width, int height, int internal_format,
+ int name, int pitch, void *loaderPrivate)
+{
+__DRIimage *image;
+struct intel_context *intel = context-driverPrivate;
+int cpp;
+
+image = CALLOC(sizeof *image);
+image-internal_format = internal_format;
+switch (internal_format) {
+case GL_RGBA:
+ image-format = MESA_FORMAT_ARGB;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
+case GL_RGB:
+ image-format = MESA_FORMAT_XRGB;
+ image-data_type = GL_UNSIGNED_BYTE;
+ break;
+}
No love for 565 or pixmaps?
Good question. What is a sufficient way to specify the pixel format?
Internal format + datatype? That's what glTexImage2D uses and should
be enough to describe the type of content and layout of the color
components, for example GL_RGB8 + GL_UNSIGNED_INT_8_8_8_8.
That particular format/type combo is invalid for glTexImage, btw.
Alternatively we can expose the MESA_FORMAT_* values as __DRI_FORMAT_*
tokens and use that in the __DRIimage extension.
I haven't followed this too closely... but FYI, there's no guarantee
that the MESA_FORMAT_x token values won't change at any time. If you
create some __DRI_FORMAT_x tokens they should probably have different
values just to be safe.
-Brian
That would be
client-api independent, but GL tokens and types are already a
dependency in the DRI driver interface, so reusing the glTexImage2D
arguments wouldn't introduce new dependencies. The problem with this
approach is that it requires the caller to know too much about the
pixel layout. We don't actually know the pixel layout for a pixmap,
so the EGL doesn't know which layout to tell the DRI driver to use.
For DRI2 drawables, we assert that the DDX and DRI drivers agree on
the detail layout of the color components and we just need to
communicated the bits per pixel. Can we keep do that for EGLImages
too? Note, we don't need to provide enough information that clients
can map and access the pixels in the EGLImage. The various client
APIs already provide mechanisms and detail information on pixel layout
for that. We just need enough information to make sure that when we
pass buffers around, client APIs (OpenGL/OpenVG/etc) and external
users (DDX, cairo-drm, KMS) agree on the format. As such, GL_RGBA8,
for example, is enough, since the drivers will all pick the same
underlying layout.
So... I think just using the internalFormat values will be fine. The
semantics will be pick the driver preferred layout for the provided
internalFormat. Does that sounds feasible?
Kristian
--
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] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .
Roland Scheidegger wrote: On 12.02.2010 19:00, Keith Whitwell wrote: On Fri, 2010-02-12 at 09:56 -0800, Roland Scheidegger wrote: On 12.02.2010 18:42, Keith Whitwell wrote: On Fri, 2010-02-12 at 09:28 -0800, José Fonseca wrote: On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote: On 12.02.2010 14:44, michal wrote: Keith Whitwell wrote on 2010-02-12 14:28: On Fri, 2010-02-12 at 05:09 -0800, michal wrote: Keith Whitwell wrote on 2010-02-12 13:39: On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote: Module: Mesa Branch: master Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f Author: Michal Krol mic...@vmware.com Date: Fri Feb 12 13:32:35 2010 +0100 util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats. Michal, Is this more like two different users expecting two different results in those unused columns? In particular, we definitely require the missing elements to be extended to (0,0,0,1) when fetching vertex data, and probably also in OpenGL texture sampling (if we supported these formats for that). Gallium should follow D3D rules, so I've been following D3D here. Also, util_unpack_color_ub() in u_pack_color.h already sets the remaining fields to 0xff. Note that D3D doesn't have the problem with expanding vertex attribute data since you can't have X or XY vertex positions, only XYZ (with W extended to 1 as in GL) and XYZW. But surely D3D permits two-component texture coordinates, which would be PIPE_FORMAT_R32G32_FLOAT, and expanded as (r,g,0,1)... Brian added a table of differences between GL and other APIs recently to gallium/docs - does your change agree with that? Where's that exactly, I can't find it? It seems like we'd want to be able to support both usages - the alternative in texture sampling would be forcing the state tracker to generate varients of the shader when 2-component textures are bound. I would say that's an unreasonable requirement on the state tracker. It seems like in GL would want (0,0,0,1) expansion everywhere, but D3D would want differing expansions in different parts of the pipeline. That indicates a single flag in the context somewhere isn't sufficient to choose between the two. Maybe there need to be two versions of these PIPE_FORMAT_ enums to capture the different values in the missing components? EG: PIPE_FORMAT_R32G32_0001_FLOAT PIPE_FORMAT_R32G32__FLOAT ? or something along those lines?? You are right. Alternatively, follow the more sane API (GL apparently), assume 0001 as default and use the infix to override. Note it's not just GL. D3D10 uses same expansion. Only D3D9 is different. Well for texture sampling anyway, I don't know what d3d does for vertex formats. Though for most hardware it would make sense to have only one format per different expansion, and use some swizzling parameter for sampling, because that's actually how the hardware works. But not all drivers will be able to do this, unfortunately. You mean, having a swizzle in pipe_sampler_state ? It sounds a good idea. In the worst case some component will inevitably need to make shader variants with different swizzles. In this case it probably makes sense to be the pipe driver -- it's a tiny shader variation which could be done without recompiling the whole shader, but if the state tracker does it then the pipe driver will always have to recompile. In the best case it is handled by the hardware's texture sampling unit. It's in theory similar to baking the swizzle in the format as Keith suggested, but cleaner IMHO. The question is whether it makes sense to have full xwyz01 swizzles, or just 01 swizzles. Another alternative is to just add the behaviour we really need - a single flag at context creation time that says what the behaviour of the sampler should be for these textures. Then the driver wouldn't have to worry about varients or mixing two different expansions. Hardware (i965 at least) seems to have one global mode to switch between these, and that's all we need to choose the right behaviour for each state tracker. It might be simpler all round just to specify it at context creation. Yes, for rg01 vs rg11 this is easiest. It doesn't solve the depth texture mode problem though. Also, we sort of have that flag already, I think there's no reason why this needs to be separate from gl_rasterization_rules (though I guess in that case it's a bit a misnomer...) I'd prefer to avoid a big I'm a GL/DX9 context flag, and split different behaviours into different flags. Sure, a GL state tracker might set them all one way, but that doesn't mean some future state-tracker wouldn't want to use a novel combination. The GL rasterization rules flag should be renamed to reflect what
Re: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
Corbin Simpson wrote: From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Wed, 10 Feb 2010 10:39:18 -0800 Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex. Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out how to test it in this new API world. :T --- src/mesa/state_tracker/st_extensions.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index d5f5854..e2d871b 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st) /* XXX separate query for early function return? */ st-ctx-Shader.EmitContReturn = screen-get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED); + + /* Quads always follow GL provoking rules. */ + c-QuadsFollowProvokingVertexConvention = GL_FALSE; } This causes the glean clipFlat test to fail with softpipe. The gallium softpipe driver _does_ implement the quad follows provoking vertex convention. I don't have time right now to update the softpipe driver so this patch will have to wait a while. Maybe someone else can look at it sooner. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): Merge branch 'master' of git+ssh://git.freedesktop.org/git/ mesa/mesa
Feel free to add a Git Tips section to the end of that page, Karl. -Brian Karl Schultz wrote: Thanks Jose! After talking to someone who knows more about git and looking at ten or so tutorials, I was going to try rebase on the next change. Looks like that's the right thing; I don't want those merges either. I wonder if your tip could be added to mesa3d.org, in the Source Code Repository section, at the bottom. I know we don't want yet another git tutorial there, but it may help people who do occasional one-offs and don't work on anything that needs its own branch. Thanks! Karl On Thu, Feb 11, 2010 at 1:02 AM, Jose Fonseca jfons...@vmware.com wrote: Karl, When doing git pull pass the --rebase option as: git pull --rebase That will prevent these distracting tiny merges. There are also ways to set rebase as the default so that the --rebase option becomes implicit, as: git config branch.master.rebase true git config --global branch.autosetuprebase=always Jose From: mesa-commit-boun...@lists.freedesktop.org [mesa-commit-boun...@lists.freedesktop.org] On Behalf Of Karl Schultz [kschu...@kemper.freedesktop.org] Sent: Wednesday, February 10, 2010 22:30 To: mesa-com...@lists.freedesktop.org Subject: Mesa (master): Merge branch 'master' of git+ssh://git.freedesktop.org/git/ mesa/mesa Module: Mesa Branch: master Commit: 2717d9066d46bff9b015f3d17dc05ce1335d0883 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=2717d9066d46bff9b015f3d17dc05ce1335d0883 Author: Karl Schultz karl.w.schu...@gmail.com Date: Wed Feb 10 15:22:07 2010 -0700 Merge branch 'master' of git+ssh://git.freedesktop.org/git/mesa/mesa --- ___ mesa-commit mailing list mesa-com...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-commit -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev . -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium query types
Keith Whitwell wrote: On Thu, 2010-02-11 at 10:13 -0800, michal wrote: Hi, I can't find any information regarding two Gallium query types. No documentation, no source code. #define PIPE_QUERY_PRIMITIVES_GENERATED 1 #define PIPE_QUERY_PRIMITIVES_EMITTED2 Do they have something to do with NV_transform_feedback extension? If not, do they mean the number of primitves before clipping, and after clipping, respectively? It looks like these have been there since the initial commit of the gallium query code. (Use git blame p_defines.h, find the line you're interested in, then git show 09fbb383) At that stage, it looked like there was a use for them in an nvidia extension, GL_PRIMITIVES_GENERATED_NV and GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_NV. Hmmm, that commit was a long time ago. Those tokens can be removed as far as I'm concerned. It would be easy to re-add them when we implement vertex transform feedback. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] piglit statistics of swrast, softpipe, r300c, and r300g
Marek Olšák wrote: Hi, I noticed that quite a lot of piglit tests fail with swrast and softpipe. I was asked for sending my stats to ML so that people working on the software rasterizers are aware of that (I guess they already know). Please see this page: http://storm.unas.cz/drivers_compared/ The parser tests and some pretty long tests are not included. The ratio pass/all is highest for r300c and lowest for more feature-rich r300g but swrast is worse than softpipe which is a shame. Tested with git master on 6th February 2010. r300g stats are the only ones not tested with pure git master but with my own additional patches in my private (localhost) repo. I believe some of the softpipe/swrast failures have been fixed recently. Glean texUnits, pixelFormats and vertProg1 all pass for me here, for example. Some of the fixes have been in Mesa, some have been in piglit and glean. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
