Re: [Mesa3d-dev] gallium-resources branch merge
On Wed, 2010-04-07 at 18:58 -0700, Marek Olšák wrote: On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. I've pushed a change which hopefully corrects the behaviour of the buffer_range inlines. Can you give it a try? Now glean/bufferObject fails on softpipe and r300g. I haven't tested other drivers. OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. 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
[Mesa3d-dev] RFC: Add missing D3D9 color formats
The attached patch adds missing D3D9 color formats. We've been going back and forward whether to add these or not, but the end conclusion seems there is no harm to add these formats, no matter how weird some are, as state tracker and pipe drivers are free to ignore them. The util module should support all formats however, for everybody's convenience. I'll submit more code for these once this patches go in. If I'm not mistaken, the only missing D3D9 formats are some depth stencil plus some video formats (e.g. NV12). I did not bother to add these yet, given I have no pressing need. Jose diff --git a/src/gallium/auxiliary/util/u_format.csv b/src/gallium/auxiliary/util/u_format.csv index f23352f..6b89a84 100644 --- a/src/gallium/auxiliary/util/u_format.csv +++ b/src/gallium/auxiliary/util/u_format.csv @@ -72,11 +72,13 @@ PIPE_FORMAT_B5G5R5A1_UNORM, plain, 1, 1, un5 , un5 , un5 , un1 , zyxw, r PIPE_FORMAT_B4G4R4A4_UNORM, plain, 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_B5G6R5_UNORM , plain, 1, 1, un5 , un6 , un5 , , zyx1, rgb PIPE_FORMAT_R10G10B10A2_UNORM , plain, 1, 1, un10, un10, un10, un2 , xyzw, rgb +PIPE_FORMAT_B10G10R10A2_UNORM , plain, 1, 1, un10, un10, un10, un2 , zyxw, rgb # Luminance/Intensity/Alpha formats PIPE_FORMAT_L8_UNORM , plain, 1, 1, un8 , , , , xxx1, rgb PIPE_FORMAT_A8_UNORM , plain, 1, 1, un8 , , , , 000x, rgb PIPE_FORMAT_I8_UNORM , plain, 1, 1, un8 , , , , , rgb +PIPE_FORMAT_L4A4_UNORM, plain, 1, 1, un4 , un4 , , , xxxy, rgb PIPE_FORMAT_L8A8_UNORM, plain, 1, 1, un8 , un8 , , , xxxy, rgb PIPE_FORMAT_L16_UNORM , plain, 1, 1, un16, , , , xxx1, rgb @@ -94,6 +96,7 @@ PIPE_FORMAT_X8R8G8B8_SRGB , plain, 1, 1, x8 , un8 , un8 , un8 , yzw1, s # Mixed-sign formats (typically used for bump map textures) PIPE_FORMAT_R8SG8SB8UX8U_NORM , plain, 1, 1, sn8 , sn8 , un8 , x8 , xyz1, rgb +PIPE_FORMAT_R10SG10SB10SA2U_NORM , plain, 1, 1, sn10, sn10, sn10, un2 , xyzw, rgb PIPE_FORMAT_R5SG5SB6U_NORM, plain, 1, 1, sn5 , sn5 , un6 , , xyz1, rgb # Depth-stencil formats @@ -121,6 +124,8 @@ PIPE_FORMAT_R10G10B10A2_USCALED , plain, 1, 1, u10 , u10 , u10 , u2 , x PIPE_FORMAT_R11G11B10_FLOAT , plain, 1, 1, f11 , f11 , f10 , , xyz1, rgb PIPE_FORMAT_R9G9B9E5_FLOAT, other, 1, 1, x32 , , , , xyz1, rgb PIPE_FORMAT_R1_UNORM , other, 8, 1, x8 , , , , x001, rgb +# A.k.a. D3DFMT_CxV8U8 +PIPE_FORMAT_R8G8Bx_SNORM , other, 1, 1, sn8 , sn8 , , , xyz1, rgb # Compressed formats # - http://en.wikipedia.org/wiki/S3_Texture_Compression @@ -171,10 +176,6 @@ PIPE_FORMAT_R32_SSCALED , plain, 1, 1, s32 , , , , x001, r PIPE_FORMAT_R32G32_SSCALED, plain, 1, 1, s32 , s32 , , , xy01, rgb PIPE_FORMAT_R32G32B32_SSCALED , plain, 1, 1, s32 , s32 , s32 , , xyz1, rgb PIPE_FORMAT_R32G32B32A32_SSCALED , plain, 1, 1, s32 , s32 , s32 , s32 , xyzw, rgb -PIPE_FORMAT_R32_FIXED , plain, 1, 1, h32 , , , , x001, rgb -PIPE_FORMAT_R32G32_FIXED , plain, 1, 1, h32 , h32 , , , xy01, rgb -PIPE_FORMAT_R32G32B32_FIXED , plain, 1, 1, h32 , h32 , h32 , , xyz1, rgb -PIPE_FORMAT_R32G32B32A32_FIXED, plain, 1, 1, h32 , h32 , h32 , h32 , xyzw, rgb PIPE_FORMAT_R16_FLOAT , plain, 1, 1, f16 , , , , x001, rgb PIPE_FORMAT_R16G16_FLOAT , plain, 1, 1, f16 , f16 , , , xy01, rgb PIPE_FORMAT_R16G16B16_FLOAT , plain, 1, 1, f16 , f16 , f16 , , xyz1, rgb @@ -211,3 +212,18 @@ PIPE_FORMAT_R8_SSCALED, plain, 1, 1, s8 , , , , x001, r PIPE_FORMAT_R8G8_SSCALED , plain, 1, 1, s8 , s8 , , , xy01, rgb PIPE_FORMAT_R8G8B8_SSCALED, plain, 1, 1, s8 , s8 , s8 , , xyz1, rgb PIPE_FORMAT_R8G8B8A8_SSCALED , plain, 1, 1, s8 , s8 , s8 , s8 , xyzw, rgb + +# GL-specific vertex buffer element formats +# A.k.a. GL_FIXED +PIPE_FORMAT_R32_FIXED , plain, 1, 1, h32 , , , , x001, rgb +PIPE_FORMAT_R32G32_FIXED , plain, 1, 1, h32 , h32 , , , xy01, rgb +PIPE_FORMAT_R32G32B32_FIXED , plain, 1, 1, h32 , h32 , h32 , , xyz1, rgb +PIPE_FORMAT_R32G32B32A32_FIXED, plain, 1, 1, h32 , h32 , h32 , h32 , xyzw, rgb + +# D3D9-specific vertex buffer element formats +# See also: +# - http://msdn.microsoft.com/en-us/library/bb172533.aspx +# A.k.a. D3DDECLTYPE_UDEC3 +PIPE_FORMAT_R10G10B10X2_USCALED , plain, 1, 1, u10 , u10 , u10 , x2 , xyz1, rgb +# A.k.a. D3DDECLTYPE_DEC3N +PIPE_FORMAT_R10G10B10X2_SNORM , plain, 1, 1, sn10, sn10, sn10 , x2 , xyz1, rgb diff --git a/src/gallium/include/pipe/p_format.h b/src/gallium/include/pipe/p_format.h index c7a90a0..a919809 100644 ---
Re: [Mesa3d-dev] RFC: Add missing D3D9 color formats
On Thu, 2010-04-08 at 09:33 -0700, José Fonseca wrote: The attached patch adds missing D3D9 color formats. We've been going back and forward whether to add these or not, but the end conclusion seems there is no harm to add these formats, no matter how weird some are, as state tracker and pipe drivers are free to ignore them. The util module should support all formats however, for everybody's convenience. I'll submit more code for these once this patches go in. If I'm not mistaken, the only missing D3D9 formats are some depth stencil plus some video formats (e.g. NV12). I did not bother to add these yet, given I have no pressing need. Jose This seems fine. Some of these may actually exist in hardware. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] crossbar: read from back buffer, not front.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This change isn't correct. This causes the test to read from the back buffer after the call to glutSwapBuffers. The swap buffer call can, especially on DRI2, cause the backbuffer to be filled with garbage. This can cause the test to fail when nothing is wrong. commit eb141ce29ef8d7f411f66afbb323f33e3eac4d80 Author: Dave Airlie airl...@redhat.com Date: Sat Apr 3 14:53:01 2010 +1000 crossbar: read from back buffer, not front. This test isn't a front buffer readback test so don't fail if front buffer readback has issues. Signed-off-by: Dave Airlie airl...@redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku+JlQACgkQX1gOwKyEAw9NPwCfbJhWHiD6S037MQEO57W64jOP U4IAn3HvXESdbll1PDWJP7zMM5U1ruNX =MSC+ -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote: OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a mapped range, the current behavior in debug build doesn't allow to flush its subrange if it doesn't touch the last byte of the range. The attached patch fixes that and changes u_uploadmgr for the mapped and flushed ranges to match. Please review. Other than that, it's stable as master. Thank you very much. -Marek From d351a37e320dcb027c43311dc620d44fdffa0a6d Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com Date: Sat, 3 Apr 2010 07:58:34 +0200 Subject: [PATCH] util: fix assertion failures in pipe_buffer_flush_mapped_range --- src/gallium/auxiliary/util/u_inlines.h|2 +- src/gallium/auxiliary/util/u_upload_mgr.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/util/u_inlines.h b/src/gallium/auxiliary/util/u_inlines.h index b1f2285..f9cd4e1 100644 --- a/src/gallium/auxiliary/util/u_inlines.h +++ b/src/gallium/auxiliary/util/u_inlines.h @@ -223,7 +223,7 @@ pipe_buffer_flush_mapped_range(struct pipe_context *pipe, assert(length); assert(transfer-box.x = offset); - assert(transfer-box.x + transfer-box.width = offset + length); + assert(offset + length = transfer-box.x + transfer-box.width); /* Match old screen-buffer_flush_mapped_range() behaviour, where * offset parameter is relative to the start of the buffer, not the diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c b/src/gallium/auxiliary/util/u_upload_mgr.c index f8c3954..75d4443 100644 --- a/src/gallium/auxiliary/util/u_upload_mgr.c +++ b/src/gallium/auxiliary/util/u_upload_mgr.c @@ -95,7 +95,7 @@ my_buffer_write(struct pipe_context *pipe, assert(dirty_size = size); assert(size); - map = pipe_buffer_map_range(pipe, buf, offset, size, + map = pipe_buffer_map_range(pipe, buf, offset, dirty_size, PIPE_TRANSFER_WRITE | PIPE_TRANSFER_FLUSH_EXPLICIT | PIPE_TRANSFER_DISCARD | -- 1.6.3.3 -- 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] Move lists to freedesktop.org?
On Thu, Apr 8, 2010 at 6: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. -Brian Are there plans to move dri-devel as well? Alex -- 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, 8 Apr 2010 18:38:03 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Apr 8, 2010 at 6: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. -Brian Are there plans to move dri-devel as well? Yeah, I'm just getting the info for that now. But I don't think we have subscriber lists, so everyone will have to re-subscribe to the new list. I'll send out a note to dri-devel when it's all set. -- Jesse Barnes, Intel Open Source Technology Center -- 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 16:37, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 8 Apr 2010 18:38:03 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Apr 8, 2010 at 6: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. -Brian Are there plans to move dri-devel as well? Yeah, I'm just getting the info for that now. But I don't think we have subscriber lists, so everyone will have to re-subscribe to the new list. I'll send out a note to dri-devel when it's all set. You can get the subscriber list at: http://lists.freedesktop.org/mailman/listinfo/dri-devel Stephane -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] glx: Fix config chooser logic for 'mask' matching
When matching attributes using the 'mask' matching criteria, the spec
says that
Only GLXFBConfigs for which the set bits of attribute include all
the bits that are set in the requested value are
considered. (Additional bits might be set in the attribute).
The current test returns true if the two bit masks have bits in
common, specifically it matches even if the requested value has bits
set that are not set in the fbconfig attribute. For example, an
application asking for
GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
---
src/glx/glxcmds.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 7cdd42c..e256a07 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1110,6 +1110,13 @@ init_fbconfig_for_chooser(__GLcontextModes * config,
} \
} while ( 0 )
+/* Test that all bits from a are contained in b */
+#define MATCH_MASK(param) \
+ do { \
+if ((a-param ~b-param) != 0) \
+ return False;\
+ } while (0);
+
/**
* Determine if two GLXFBConfigs are compatible.
*
@@ -1148,11 +1155,8 @@ fbconfigs_compatible(const __GLcontextModes * const a,
MATCH_DONT_CARE(stereoMode);
MATCH_EXACT(level);
- if (((a-drawableType b-drawableType) == 0)
- || ((a-renderType b-renderType) == 0)) {
- return False;
- }
-
+ MATCH_MASK(drawableType);
+ MATCH_MASK(renderType);
/* There is a bug in a few of the XFree86 DDX drivers. They contain
* visuals with a transparent type of 0 when they really mean GLX_NONE.
--
1.7.0.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] u_half.? - u_format_half.? rename
I named it that way because it is datatype conversion functionality, which is conceptually a lower layer than format conversion, which operates on multi-component formats, and is also totally independent of the existing format conversion functionality. It is the only member of that layer because all other currently needed datatype conversions can be performed with trivial C language expressions: this could change as other unusual floating point datatypes are needed (e.g. 6e5 and 5e5 for EXT_packed_float). That said, feel free to rename it: it's just a cosmetic issue. Alternatively, maybe it a new data conversion prefix could be invented, like u_convert_half.* or something like that. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
