Re: [Mesa-dev] Mesa (d3d1x): d3d1x: add new Direct3D 10/11 COM state tracker for Gallium
On 9/21/2010 9:37 PM, James McKenzie wrote: I just read a comment that you made in the Mesa mailing list and am seriously concerned about it: It only attempts to prevent reverse engineering, disassembly and decompilation, and does not grant you distribution rights under copyright law in the case that you distribute Microsoft code to run on non-Windows platform or license it under a copyleft license. Please keep in mind that Microsoft has been 'tightening' their EULA agreements. Before you go out and do something like what you expressed here: "I just looked at the d3d11TokenizedProgramFormat.h header because the documentation on MSDN says that the shader bytecode format is documented in that file" bear that Microsoft does track what is being done with their code. If you step over the line, they will 'nail' you. They give absolutely NO warning. One user decided to work with WMP 10 to get it to work under RedHat. He was given a court order to 'cease and desist' all work in this manner. This is why the Wine project and its predecessors Project Odinn and the WineOS/2 project have always kept a hands off and no peaking 'under the hood' policy. No FOSS project wants a visit from any Justice Department, any Copyright office and lastly no visit from the Thugs Who Work for Microsoft. Again, if you feel that what you did is justified, then you are so. Also, keep in mind that your code can be blocked in countries that strictly enforce the Microsoft EULAs (the United States is one of them.) Very respectfully, James McKenzie I'm not a lawyer, and I don't play one on TV. However, I have been around for the US versus IBM and US versus Microsoft cases The US Government lost both of them. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev I hate hate hate to ask, but doesn't this precedent http://en.wikipedia.org/wiki/Sega_v._Accolade cover it? It seems like it'd be hard to argue that this examining of copyrighted material wasn't done for the sake of interoperability and that there were other means of figuring out what these tokens might be. This probably isn't the place to have such a discussion, but I'd bet $20 that this would be upheld, you know, if Microsoft didn't appeal the case until the defendant ran out of money. Such is America. :\ Patrick ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30220] Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c ?
https://bugs.freedesktop.org/show_bug.cgi?id=30220 --- Comment #3 from Christopher James Halse Rogers 2010-09-22 00:42:15 PDT --- The code posted applies to mesa 7.8, but has been removed in 7.9. It would be useful to a) Test if this bug still applies to mesa 7.9 from git (I've been told it applies to a snapshot from 2010/09/09, but haven't been able to reproduce it myself). and if it still occurs, then b) Port the patch to the 7.9 branch & master. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29910] Mesa advertises bogus GL_ARB_shading_language_120
https://bugs.freedesktop.org/show_bug.cgi?id=29910 --- Comment #9 from Kenneth Graunke 2010-09-22 01:00:15 PDT --- Created an attachment (id=38867) View: https://bugs.freedesktop.org/attachment.cgi?id=38867 Review: https://bugs.freedesktop.org/review?bug=29910&attachment=38867 Patch that compiles, but doesn't work -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29910] Mesa advertises bogus GL_ARB_shading_language_120
https://bugs.freedesktop.org/show_bug.cgi?id=29910 --- Comment #10 from Kenneth Graunke 2010-09-22 01:03:57 PDT --- Unfortunately, the patch breaks the build for me: brw_context.c:45:35: error: array type has incomplete element type brw_context.c:46:22: error: ‘GL_VERSION_2_1_functions’ undeclared here (not in a function) brw_context.c: In function ‘brwCreateContext’: brw_context.c:163:4: warning: implicit declaration of function ‘driInitExtensions’ brw_context.c: At top level: brw_context.c:45:35: warning: ‘gl_21_extension’ defined but not used I attached a patch which moves this to intel_extensions.c, where it probably belongs...unfortunately, it doesn't /work/...running a random piglit test gives: Mesa 7.10-devel implementation error: Trying to enable unknown extension: GL_VERSION_2_1 Perhaps you really just want to call _mesa_enable_2_1_extensions? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] separate depth and stencil buffers in gallium
So Evergreen hardware appears to have only completely separate depth and stencil buffers and doesn't natively support a combnined DS buffer from what I can see. I'm awaiting clarification from AMD. Now gallium and st/mesa seem to be quite dedicated to the whole combined DS cause. I'm mainly posting just wondering if anyone else has considered this or any other hardware this might be useful for exists, or if anyone can speak to the pitfalls I'll face. I've got some initial done in 30 mins hacks http://cgit.freedesktop.org/~airlied/mesa/log/?h=sep-zs Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] separate depth and stencil buffers in gallium
On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie wrote: > So Evergreen hardware appears to have only completely separate depth > and stencil buffers and doesn't natively support a combnined DS buffer > from what I can see. I'm awaiting clarification from AMD. > > Now gallium and st/mesa seem to be quite dedicated to the whole > combined DS cause. What formats exactly does it support? It's interesting because DX10 (and presumably 11) always talk about combined buffers - but the abstraction is such (with staging resources, no direct mapping of the buffers, etc) that there's nothing which constrains the layout to be an interleaved depth+stencil. IE. you could quite happily allocate the combined depth/stencil as a planar depth buffer and a separate planar stencil buffer - both hidden behind the same resource handle. I would have hoped we'd have the same flexibility in gallium - basically that nobody should be able to tell whether depth & stencil are swizzled together or separate. The obvious case where the app & state tracker might be alerted to your unusual layout is in transfers. An interim solution would be to swizzle/unswizzle depth buffer transfer data (or organize for the card to do so for you). > I'm mainly posting just wondering if anyone else has considered this > or any other hardware this might be useful for exists, or if anyone > can speak to the pitfalls I'll face. > > I've got some initial done in 30 mins hacks > http://cgit.freedesktop.org/~airlied/mesa/log/?h=sep-zs I'll take a look. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] separate depth and stencil buffers in gallium
On Wed, Sep 22, 2010 at 7:50 PM, Keith Whitwell wrote: > On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie wrote: >> So Evergreen hardware appears to have only completely separate depth >> and stencil buffers and doesn't natively support a combnined DS buffer >> from what I can see. I'm awaiting clarification from AMD. >> >> Now gallium and st/mesa seem to be quite dedicated to the whole >> combined DS cause. > > What formats exactly does it support? It looks like Z16,24 and a 32-float, along with I think an S8 stencil (its a one bit format). I'm not sure if the Z24 is packed or its actually X8Z24, this only matters when I need to know what size buffers to allocate in the DDX for passing over DRI2. > > It's interesting because DX10 (and presumably 11) always talk about > combined buffers - but the abstraction is such (with staging > resources, no direct mapping of the buffers, etc) that there's nothing > which constrains the layout to be an interleaved depth+stencil. IE. > you could quite happily allocate the combined depth/stencil as a > planar depth buffer and a separate planar stencil buffer - both hidden > behind the same resource handle. Yeah thats what I'm wondering if I should just hide this all in the driver resource handling. The hw is a bit messy anyways, we can't attach DB direct to texture, we have to flush it out via a DB->CB rendering pass, so I think its probably possible with sufficent shader to make it produce a combined ZS from the separated buffers. I' > I would have hoped we'd have the same flexibility in gallium - > basically that nobody should be able to tell whether depth & stencil > are swizzled together or separate. > > The obvious case where the app & state tracker might be alerted to > your unusual layout is in transfers. An interim solution would be to > swizzle/unswizzle depth buffer transfer data (or organize for the card > to do so for you). > > >> I'm mainly posting just wondering if anyone else has considered this >> or any other hardware this might be useful for exists, or if anyone >> can speak to the pitfalls I'll face. >> >> I've got some initial done in 30 mins hacks >> http://cgit.freedesktop.org/~airlied/mesa/log/?h=sep-zs So I'm guessing I've taken the wrong approach here from reading this, I should probably not expose this to gallium, and just make sure the DDX allocates a large enough buffer for two planes. Hopefully Alex can dig out some more info. Thanks, Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] separate depth and stencil buffers in gallium
On Wed, Sep 22, 2010 at 11:15 AM, Dave Airlie wrote: >>> I'm mainly posting just wondering if anyone else has considered this >>> or any other hardware this might be useful for exists, or if anyone >>> can speak to the pitfalls I'll face. >>> >>> I've got some initial done in 30 mins hacks >>> http://cgit.freedesktop.org/~airlied/mesa/log/?h=sep-zs > > So I'm guessing I've taken the wrong approach here from reading this, > I should probably not expose this to gallium, and just make sure the DDX > allocates a large enough buffer for two planes. > This sounds good, especially if sampling needs yet more logic. Presumably things like Hyper-Z require their own, additional storage? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] separate depth and stencil buffers in gallium
On Wed, Sep 22, 2010 at 8:20 PM, Keith Whitwell wrote: > On Wed, Sep 22, 2010 at 11:15 AM, Dave Airlie wrote: > I'm mainly posting just wondering if anyone else has considered this or any other hardware this might be useful for exists, or if anyone can speak to the pitfalls I'll face. I've got some initial done in 30 mins hacks http://cgit.freedesktop.org/~airlied/mesa/log/?h=sep-zs >> >> So I'm guessing I've taken the wrong approach here from reading this, >> I should probably not expose this to gallium, and just make sure the DDX >> allocates a large enough buffer for two planes. >> > > This sounds good, especially if sampling needs yet more logic. > > Presumably things like Hyper-Z require their own, additional storage? the HiZ/HiS on r600 needs VRAM allocated, thinking about it now I wonder if we need to group that allocation with the depth alloc, esp for the whole GLX context sharing stuff. I suppose r300g has similar issues, though the HiZ/Zmask on those GPUs is internal. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30220] Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c ?
https://bugs.freedesktop.org/show_bug.cgi?id=30220 --- Comment #4 from jpsinthe...@verizon.net 2010-09-22 03:44:59 PDT --- (In reply to comment #3) > The code posted applies to mesa 7.8, but has been removed in 7.9. It would be > useful to > a) Test if this bug still applies to mesa 7.9 from git (I've been told it > applies to a snapshot from 2010/09/09, but haven't been able to reproduce it > myself). > > and if it still occurs, then > b) Port the patch to the 7.9 branch & master. Thanks for looking at this. So, do I understand correctly, that the patch is ok on Mesa-7.8.x ? If this is so, then everyone now using KDE-4.5.x (and presumably Mesa-7.8.x), can use it. I'd love also to test it out on 7.9 -- but I tried several weeks ago and ran into trouble -- I think with the intel driver (xf86-video-intel-2.12.0). I'll try again and get back to you on this. Have you or anyone had a chance to look at BUG #30217 ? thanks again -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30124] Mesa 7.9 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=30124 Bug 30124 depends on bug 29849, which changed state. Bug 29849 Summary: [llvmpipe] piglit glsl-fs-pointcoord regression https://bugs.freedesktop.org/show_bug.cgi?id=29849 What|Old Value |New Value Resolution||FIXED Status|REOPENED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Current tinderbox regression (mesa dri/i965)
http://tinderbox.x.org/builds/2010-09-22-0001/logs/libGL/#build brw_context.c:45: error: array type has incomplete element type brw_context.c:46: error: 'GL_VERSION_2_1_functions' undeclared here brw_context.c: In function 'brwCreateContext': brw_context.c:163: warning: implicit declaration of function 'driInitExtensions' gmake[6]: *** [brw_context.o] Error 1 -- Chris Ball One Laptop Per Child ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29910] Mesa advertises bogus GL_ARB_shading_language_120
https://bugs.freedesktop.org/show_bug.cgi?id=29910 --- Comment #11 from Kristian Høgsberg 2010-09-22 08:09:30 PDT --- commit b91dba49e0b08b18dbd6c477facdcc7b5472c8c7 Author: Kristian Høgsberg Date: Wed Sep 22 11:01:11 2010 -0400 intel: Fix GL_ARB_shading_language_120 commit Fix commit e7087175f8a04f777403366fb34b58edd00f4d60. Move the reference to GL_VERSION_2_1_functions to intel_extensions.c where it's available, don't try to enable a non-existing extension and advertise 1.20 for all intel chipsets, not just GEN4 and up. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Current tinderbox regression (mesa dri/i965)
Should be fixed by b91dba49e0b08b18dbd6c477facdcc7b5472c8c7. On Wed, Sep 22, 2010 at 9:47 AM, Chris Ball wrote: > http://tinderbox.x.org/builds/2010-09-22-0001/logs/libGL/#build > > brw_context.c:45: error: array type has incomplete element type > brw_context.c:46: error: 'GL_VERSION_2_1_functions' undeclared here > brw_context.c: In function 'brwCreateContext': > brw_context.c:163: warning: implicit declaration of function > 'driInitExtensions' > gmake[6]: *** [brw_context.o] Error 1 > > -- > Chris Ball > One Laptop Per Child > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Current tinderbox regression (mesa dri/i965)
Thanks, Kristian. I was about to commit a similar fix. -Brian 2010/9/22 Kristian Høgsberg : > Should be fixed by b91dba49e0b08b18dbd6c477facdcc7b5472c8c7. > > On Wed, Sep 22, 2010 at 9:47 AM, Chris Ball wrote: >> http://tinderbox.x.org/builds/2010-09-22-0001/logs/libGL/#build >> >> brw_context.c:45: error: array type has incomplete element type >> brw_context.c:46: error: 'GL_VERSION_2_1_functions' undeclared here >> brw_context.c: In function 'brwCreateContext': >> brw_context.c:163: warning: implicit declaration of function >> 'driInitExtensions' >> gmake[6]: *** [brw_context.o] Error 1 >> >> -- >> Chris Ball >> One Laptop Per Child >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30318] [glsl2] glean glsl1 test "texcoord varying" does not work
https://bugs.freedesktop.org/show_bug.cgi?id=30318 --- Comment #1 from Ian Romanick 2010-09-22 09:47:57 PDT --- We removed this test from the piglit list because we determined that the test was incorrect. By default gl_TexCoord is declared as 'vec4 gl_TexCoord[]' (dimensionless). The spec says that an array accessed with an index that is not a constant valued expression must be dimensioned. Here's the piglit commit: commit c6146f121e2f9319aa87631dcc024b208acf7829 Author: Eric Anholt Date: Thu Aug 5 16:20:15 2010 -0700 glean: Flag the glsl1 test "texcoord varying" as being invalid GLSL. It accesses the builtin unsized array gl_TexCoord[] with a non-constant expression without sizing the array first. See piglit glsl-texcoord-array for a working version of this tset. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29910] Mesa advertises bogus GL_ARB_shading_language_120
https://bugs.freedesktop.org/show_bug.cgi?id=29910 --- Comment #12 from Ian Romanick 2010-09-22 09:51:08 PDT --- This looks fine for now, and I'm going to cherry-pick both patches to 7.9. In the future we will want to expose the supported versions as a bitmask. In later versions of OpenGL core profile the older shading languages cease to be supported. This may also allow a more unified method for testing support for GLSL ES (which is version 1.00). There will be a lot of other changes required to support this, so we can cross that bridge when we come to it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30318] [glsl2] glean glsl1 test "texcoord varying" does not work
https://bugs.freedesktop.org/show_bug.cgi?id=30318 --- Comment #2 from Brian Paul 2010-09-22 10:01:02 PDT --- OK, it looks like this changed at some point. The original GLSL Orange book defined the array as varying vec4 gl_TexCoord[gl_MaxTextureCoords]. I'd rather see the glean test fixed than flagged as illegal though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30318] [glsl2] glean glsl1 test "texcoord varying" does not work
https://bugs.freedesktop.org/show_bug.cgi?id=30318 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Brian Paul 2010-09-22 10:03:57 PDT --- Fixed glean glsl1 "texcoord varying" with commit 390b0392f25dc85080a9a5c2a69926c290873e38 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30124] Mesa 7.9 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=30124 Bug 30124 depends on bug 29848, which changed state. Bug 29848 Summary: [llvmpipe] piglit point-sprite regression https://bugs.freedesktop.org/show_bug.cgi?id=29848 What|Old Value |New Value Resolution||FIXED Status|REOPENED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Removing ARB_imaging subset extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakob Bornecrantz wrote: > On 20 sep 2010, at 19.58, Luca Barbieri wrote: >> nVidia dropped hardware support starting from nv40. >> >> For texture compression, S3TC or R-component-only textures should >> usually be a better option, and for other uses shader-based techniques >> are more flexible. > > The advantage is that lookup is done before filtering, while with > shaders you need to do the filtering yourself. > > IIRC from XDS weren't there some ES extension that actually fit what > hardware does better, or doesn't it fit the needs of apps as well? Then > again I'm not for keeping this code. On OpenGL ES there is GL_OES_compressed_paletted_texture. http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_paletted_texture.txt I got to thinking about paletted textures a bit more. The OES extension isn't that much better for us. Hardware still can't really use palettes because you can still have the case where there are more texture palettes than hardware palettes. This means that hardware with fewer hardware palettes than texture units has to expand every texture to full RGBA all the time. That basically makes the extension worthless. The one advantage of the OES extension over the EXT is that the palette is fixed at texture upload in the OES version. In the EXT version the palette can change at any time. It seems that if we want to support any of this, including the OES extension, we want a way to have both a paletted and an RGBA version of each texture. This allows the driver to pick the version of the texture that will work at any time. If we care about supporting the OES extension, the existing palette support should probably stay. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaSwIACgkQX1gOwKyEAw/5vACfWMkY7gdHDOSOKkg3iH8Xk0f9 Ag4An2BIChVpee7UrPuS/pk1jan8PVFN =nPLl -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30333] New: DXT compressed SRGB textures cause assert failure
https://bugs.freedesktop.org/show_bug.cgi?id=30333 Summary: DXT compressed SRGB textures cause assert failure Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: thomas.jo...@utoronto.ca If a SRGB compressed format is chosen as the internal format of a texture that is not already compressed the compression will cause an assertion fail in a debug build of mesa because the assert is too narrow, it should accept sRGB compressed destination formats as well. main/texcompress_s3tc.c:170: _mesa_texstore_rgb_dxt1: Assertion `dstFormat == MESA_FORMAT_RGB_DXT1' failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] separate depth and stencil buffers in gallium
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Airlie wrote: > So Evergreen hardware appears to have only completely separate depth > and stencil buffers and doesn't natively support a combnined DS buffer > from what I can see. I'm awaiting clarification from AMD. > > Now gallium and st/mesa seem to be quite dedicated to the whole > combined DS cause. > > I'm mainly posting just wondering if anyone else has considered this > or any other hardware this might be useful for exists, or if anyone > can speak to the pitfalls I'll face. Since separate depth / stencil is a required feature in some late version of DX (11?), you can be sure that it will start appearing in other hardware over the next year or so. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyabzUACgkQX1gOwKyEAw86xACeMyYwMTCoxb5JVX4NCL77u9Ts cIgAn389lmLmkqGaoOwi4ZhC1NpEMKrG =5H3N -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Add more sandybridge device ids.
From: Robert Hooker This prevents failures like this when using one of these devices: Unrecognized deviceID 116 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Serial number of failed request: 21 Current serial number in output stream: 24 The full list of new id's was obtained from commit 53767cc0d0a58d36cd445d in xf86-video-intel. Signed-off-by: Robert Hooker --- src/mesa/drivers/dri/intel/intel_chipset.h | 20 ++-- src/mesa/drivers/dri/intel/intel_context.c | 11 +++ 2 files changed, 25 insertions(+), 6 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h b/src/mesa/drivers/dri/intel/intel_chipset.h index b5f180b..b17e608 100644 --- a/src/mesa/drivers/dri/intel/intel_chipset.h +++ b/src/mesa/drivers/dri/intel/intel_chipset.h @@ -71,9 +71,13 @@ #define PCI_CHIP_ILD_G 0x0042 #define PCI_CHIP_ILM_G 0x0046 -#define PCI_CHIP_SANDYBRIDGE 0x0102 -#define PCI_CHIP_SANDYBRIDGE_M 0x0106 -#define PCI_CHIP_SANDYBRIDGE_M_D0 0x0126 +#define PCI_CHIP_SANDYBRIDGE_GT1 0x0102 +#define PCI_CHIP_SANDYBRIDGE_GT2 0x0112 +#define PCI_CHIP_SANDYBRIDGE_GT2_PLUS 0x0122 +#define PCI_CHIP_SANDYBRIDGE_M_GT1 0x0106 +#define PCI_CHIP_SANDYBRIDGE_M_GT2 0x0116 +#define PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS0x0126 +#define PCI_CHIP_SANDYBRIDGE_S_GT 0x010A #define IS_MOBILE(devid) (devid == PCI_CHIP_I855_GM || \ devid == PCI_CHIP_I915_GM || \ @@ -119,9 +123,13 @@ /* Compat macro for intel_decode.c */ #define IS_IRONLAKE(devid) IS_GEN5(devid) -#define IS_GEN6(devid) (devid == PCI_CHIP_SANDYBRIDGE || \ -devid == PCI_CHIP_SANDYBRIDGE_M || \ -devid == PCI_CHIP_SANDYBRIDGE_M_D0) +#define IS_GEN6(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT1 || \ +devid == PCI_CHIP_SANDYBRIDGE_GT2 || \ +devid == PCI_CHIP_SANDYBRIDGE_GT2_PLUS || \ +devid == PCI_CHIP_SANDYBRIDGE_M_GT1 || \ +devid == PCI_CHIP_SANDYBRIDGE_M_GT2 || \ +devid == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS || \ +devid == PCI_CHIP_SANDYBRIDGE_S_GT) #define IS_965(devid) (IS_GEN4(devid) || \ IS_G4X(devid) || \ diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index 109c670..a12e90a 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -163,6 +163,17 @@ intelGetString(GLcontext * ctx, GLenum name) case PCI_CHIP_ILM_G: chipset = "Intel(R) Ironlake Mobile"; break; + case PCI_CHIP_SANDYBRIDGE_GT1: + case PCI_CHIP_SANDYBRIDGE_GT2: + case PCI_CHIP_SANDYBRIDGE_GT2_PLUS: + case PCI_CHIP_SANDYBRIDGE_S_GT: + chipset = "Intel(R) Sandybridge Desktop"; + break; + case PCI_CHIP_SANDYBRIDGE_M_GT1: + case PCI_CHIP_SANDYBRIDGE_M_GT2: + case PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS: + chipset = "Intel(R) Sandybridge Mobile"; + break; default: chipset = "Unknown Intel Chipset"; break; -- 1.7.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] D3D1x Revert
Can I revert this merge out of master? The Wine developers that contribute to Mesa are feeling very alienated by this code, and I think that it could stand to have some more discussion, especially about its legality. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30335] New: commit 17eace581d25a626a7d75d9d1205d012cbb14a6e broke mesa
https://bugs.freedesktop.org/show_bug.cgi?id=30335 Summary: commit 17eace581d25a626a7d75d9d1205d012cbb14a6e broke mesa Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: blocker Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: virtuous...@gmail.com after commit 17eace581d25a626a7d75d9d1205d012cbb14a6e building fails with: x86_64-pc-linux-gnu-gcc -m32 -c -o state_tracker/st_manager.o state_tracker/st_manager.c -DFEATURE_GL=1 -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -I../../include -I../../src/glsl -I../../src/mesa -I../../src/mapi -I../../src/gallium/include -I../../src/gallium/auxiliary -march=k8-sse3 -O2 -pipe -ffast-math -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM state_tracker/st_manager.c: In function ‘st_manager_get_egl_image_surface’: state_tracker/st_manager.c:797:4: error: too many arguments to function ‘smapi->get_egl_image’ gmake[2]: *** [state_tracker/st_manager.o] Error 1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30335] commit 17eace581d25a626a7d75d9d1205d012cbb14a6e broke mesa
https://bugs.freedesktop.org/show_bug.cgi?id=30335 Sergey Kondakov changed: What|Removed |Added AssignedTo|mesa-...@lists.freedesktop. |k...@bitplanet.net |org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] D3D1x Revert
Either WINE developers or Luca will feel alienated. So, I think the discussion should be *now*, before taking further decision. Personally, I still don't understand what's special about this code. If no Microsoft code was ever copied or used in d3d1x then I don't see how WINE developers are tainted by the d3d1x state tracker presence than by the other stuff in master now. As I said before, we all read third party NDA hardware specs and reference code in the past. It is standard practice. Several other members of the community had to reverse engineer hardware operation. I think it would be dishonest to allows ourselves this much so far, and refuse Luca's code because he read publicly available Microsoft docs or reference code. My understanding is that this is more than about legality of this code: Microsoft can sue whoever they want, with or without legal basis, and WINE developers want to publicly show beyond doubt that they we're not near even miles from Microsoft code, to deter Microsoft to sue them, and so incur in legal expenses. But I don't see how we can accommodate that, and continue to maintain that Gallium is about the abstraction of many graphic APIs and many OSes. Even Mesa was always about many OSes too. Personally, I'd like to encourage initiatives of supporting more APIs and more OSes to Mesa/Gallium such as this one. And to be honest, WINE developers did a disservice to themselves by openly stating their concerns. They put themselves between the rock and the wall with that. For future reference, if people have this sort of doubts, they should contact the project maintainers (e.g Brian, Keith) privately. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Corbin Simpson [mostawesomed...@gmail.com] Sent: Wednesday, September 22, 2010 23:23 To: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] D3D1x Revert Can I revert this merge out of master? The Wine developers that contribute to Mesa are feeling very alienated by this code, and I think that it could stand to have some more discussion, especially about its legality. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] D3D1x Revert
A way to unblock this would be to split thed3d1x state tracker in two parts: the runtime, and the client driver. As Keith also suggested. The client driver could be used on Windows -- precisely as the DDK and WDK are intended. The runtime part could be re-implemented from scratch by WINE or REACTOS, using their standard development practices. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Jose Fonseca [jfons...@vmware.com] Sent: Thursday, September 23, 2010 7:33 To: Corbin Simpson Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] D3D1x Revert Either WINE developers or Luca will feel alienated. So, I think the discussion should be *now*, before taking further decision. Personally, I still don't understand what's special about this code. If no Microsoft code was ever copied or used in d3d1x then I don't see how WINE developers are tainted by the d3d1x state tracker presence than by the other stuff in master now. As I said before, we all read third party NDA hardware specs and reference code in the past. It is standard practice. Several other members of the community had to reverse engineer hardware operation. I think it would be dishonest to allows ourselves this much so far, and refuse Luca's code because he read publicly available Microsoft docs or reference code. My understanding is that this is more than about legality of this code: Microsoft can sue whoever they want, with or without legal basis, and WINE developers want to publicly show beyond doubt that they we're not near even miles from Microsoft code, to deter Microsoft to sue them, and so incur in legal expenses. But I don't see how we can accommodate that, and continue to maintain that Gallium is about the abstraction of many graphic APIs and many OSes. Even Mesa was always about many OSes too. Personally, I'd like to encourage initiatives of supporting more APIs and more OSes to Mesa/Gallium such as this one. And to be honest, WINE developers did a disservice to themselves by openly stating their concerns. They put themselves between the rock and the wall with that. For future reference, if people have this sort of doubts, they should contact the project maintainers (e.g Brian, Keith) privately. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Corbin Simpson [mostawesomed...@gmail.com] Sent: Wednesday, September 22, 2010 23:23 To: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] D3D1x Revert Can I revert this merge out of master? The Wine developers that contribute to Mesa are feeling very alienated by this code, and I think that it could stand to have some more discussion, especially about its legality. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
