[Mesa-dev] [Bug 29646] baddrawable when resizing a window in gnome-shell/mutter
https://bugs.freedesktop.org/show_bug.cgi?id=29646 --- Comment #5 from Michel Dänzer mic...@daenzer.net 2010-09-24 00:29:00 PDT --- (In reply to comment #4) So, I'd think that if glxDestroyPixmap() can follow XDestroyPixmap() the GLX pixmap X ID has to be kept around and not deallocated in the server until glXDestroyPixmp is called (or the client exits) That is the case: Pixmaps are reference counted in the X server, and GLXPixmaps take a reference on the backing X pixmaps. -- 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 30355] compilation fails because sm4_defs.h is missing
https://bugs.freedesktop.org/show_bug.cgi?id=30355 --- Comment #2 from Martin Stolpe martinsto...@gmail.com 2010-09-24 01:59:23 PDT --- No, it doesn't compile. The reason is that there is no sm4_defs.h file in mesa/src/gallium/state_trackers/d3d1x/d3d1xshader/include/. -- 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 30355] compilation fails because sm4_defs.h is missing
https://bugs.freedesktop.org/show_bug.cgi?id=30355 --- Comment #3 from Luca Barbieri luca.barbi...@gmail.com 2010-09-24 02:09:22 PDT --- Yes, but it should be automatically generated. Are you perhaps compiling without /usr/bin/makedepend installed? If so, installing the makedepend package should fix this. I'll see whether to make it work without it, or add an hard dependency on it in Mesa. -- 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 30345] [d3d1x] EGL/egl.h - missing header
https://bugs.freedesktop.org/show_bug.cgi?id=30345 Nikolay Rysev mad.f...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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 30355] compilation fails because sm4_defs.h is missing
https://bugs.freedesktop.org/show_bug.cgi?id=30355 --- Comment #4 from Martin Stolpe martinsto...@gmail.com 2010-09-24 02:36:22 PDT --- makedepend was indeed missing. Learned something new today. ;-) On wikipedia I read, that makedepend isn't really used anymore: makedepend... has since become superseded by the dependency generation facilities of various compilers, and is now used primarily as a worst-case fallback, e.g. by depcomp and GNU Automake. I don't know any of this stuff but it would it be possible to replace this dependency. makedepend for example is not even in the official repositories of my distro (Archlinux, it's in AUR though). Anyway the compiliation still fails: g++ -march=native -mtune=native -O2 -g -mfpmath=sse -pipe -Wall -fvisibility=hidden -fno-strict-aliasing -fPIC -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 -Wl,--hash-style=gnu -Wl,--as-needed tools/dxbc2tgsi.o -o tools/dxbc2tgsi -Wl,--start-group libgd3d1x.a ../d3d1xshader/libd3d1xshader.a ../../../auxiliary/libgallium.a -ldl -Wl,--end-group libgd3d1x.a(sm4_to_tgsi.o): In function `.L1072': /home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/src/gallium/state_trackers/d3d1x/gd3d1x/sm4_to_tgsi.cpp:818: undefined reference to `d3d_to_pipe_prim_type' libgd3d1x.a(sm4_to_tgsi.o): In function `.L1071': /home/martin/abs/2_xorg/5_-_mesa-full/src/mesa-build/src/gallium/state_trackers/d3d1x/gd3d1x/sm4_to_tgsi.cpp:821: undefined reference to `d3d_to_pipe_prim' collect2: ld returned 1 exit status make[5]: *** [tools/dxbc2tgsi] 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] Making makedepend an hard dependency?
Currently makedepend is used by the Mesa Makefile-based build system, but not required. Unfortunately, not having it makes dependency resolution non-existent, which is a source of subtle bugs, and is a rarely tested configuration, since all Mesa developers likely have it installed. Furthermore some idioms require dependency resolution to work at all, such as making generated files depend on headers. How about failing configure if it's absent? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30355] compilation fails because sm4_defs.h is missing
https://bugs.freedesktop.org/show_bug.cgi?id=30355 --- Comment #5 from Luca Barbieri luca.barbi...@gmail.com 2010-09-24 03:01:02 PDT --- Unfortunately, the Mesa build system still uses makedepend. It would be a good idea to make it an hard dependency though, since it causes silent errors otherwise. The link error should now be fixed: let me know if there are any other issues. -- 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 30355] compilation fails because sm4_defs.h is missing
https://bugs.freedesktop.org/show_bug.cgi?id=30355 --- Comment #6 from Martin Stolpe martinsto...@gmail.com 2010-09-24 03:39:54 PDT --- Created an attachment (id=38928) -- (https://bugs.freedesktop.org/attachment.cgi?id=38928) mesa configure options Now it compiles. Thank you! The d3d1x state tracker is the only part of mesa which depends on makedepends with the configuration I currently use (see attachement). Perhaps it would be a good idea to make makedepends a hard dependency in case d3d1x state tracker is selected. -- 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] Making makedepend an hard dependency?
I think this is a good idea. It might reduce the number of bugs fixed by git clean -fdx + rebuild. However we have discussed this before and there were some objections. Marek On Fri, Sep 24, 2010 at 11:55 AM, Luca Barbieri l...@luca-barbieri.comwrote: Currently makedepend is used by the Mesa Makefile-based build system, but not required. Unfortunately, not having it makes dependency resolution non-existent, which is a source of subtle bugs, and is a rarely tested configuration, since all Mesa developers likely have it installed. Furthermore some idioms require dependency resolution to work at all, such as making generated files depend on headers. How about failing configure if it's absent? ___ 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] [PATCH] mesa: make makedepend an hard requirement
Currently makedepend is used by the Mesa Makefile-based build system, but not required. Unfortunately, not having it makes dependency resolution non-existent, which is a source of subtle bugs, and is a rarely tested configuration, since all Mesa developers likely have it installed. Furthermore some idioms require dependency resolution to work at all, such as making headers depend on generated files. --- configure.ac |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 2b8296d..e75224d 100644 --- a/configure.ac +++ b/configure.ac @@ -33,6 +33,10 @@ AC_CHECK_PROGS([MAKE], [gmake make]) AC_PATH_PROG([MKDEP], [makedepend]) AC_PATH_PROG([SED], [sed]) +if test x$MKDEP = x; then +AC_MSG_ERROR([makedepend is required to build Mesa]) +fi + dnl Our fallback install-sh is a symlink to minstall. Use the existing dnl configuration in that case. AC_PROG_INSTALL -- 1.7.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] cflags mess with llvm builds
When gallium llvm is enabled, configure.ac does the following : LLVM_CFLAGS=`$LLVM_CONFIG --cflags` This is the result on my system : -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC I specifically set -O0 to easier gdb debugging and -fno-omit-frame-pointer to use some profiling tools, but they were both silently overridden by llvm cflags. Also scons/llvm.py only uses cppflags, not cflags, which at least gives a better result llvm-config --cppflags : -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS then src/gallium/Makefile.template has : ifeq ($(MESA_LLVM),1) LIBRARY_DEFINES += $(LLVM_CFLAGS) endif Do we want / need these definitions for all the code in src/gallium, or is it possible to add them only in the parts that do use llvm and need the definitions from llvm-config --cppflags ? I found it weird that enabling or disabling gallium llvm resulted in nv50 gallium built with different gcc flags. From df82cdf0b9b6bd60ef47ddbf4b6d74d200382262 Mon Sep 17 00:00:00 2001 From: Xavier Chantry chantry.xav...@gmail.com Date: Fri, 24 Sep 2010 13:17:40 +0200 Subject: [PATCH] configure.ac : use llvm-config cppflags instead of cflags llvm cflags are too intrusive and override user-defined flags. cppflags are probably enough and this is what scons/llvm.py uses already. $ llvm-config --cflags -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC $ llvm-config --cppflags -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 2b8296d..c88ee5e 100644 --- a/configure.ac +++ b/configure.ac @@ -1439,7 +1439,7 @@ AC_ARG_ENABLE([gallium-llvm], if test x$enable_gallium_llvm = xyes; then if test x$LLVM_CONFIG != xno; then LLVM_VERSION=`$LLVM_CONFIG --version` - LLVM_CFLAGS=`$LLVM_CONFIG --cflags` + LLVM_CFLAGS=`$LLVM_CONFIG --cppflags` LLVM_LIBS=`$LLVM_CONFIG --libs jit interpreter nativecodegen bitwriter` -lstdc++ if test x$HAS_UDIS86 != xno; then -- 1.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Fri, Sep 24, 2010 at 14:06:51 +0200, Xavier Chantry wrote: When gallium llvm is enabled, configure.ac does the following : LLVM_CFLAGS=`$LLVM_CONFIG --cflags` This is the result on my system : -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC I'd argue that that's a bug in llvm-config, it has no business telling you what optimisation level to use, or defining random macros. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: fix util_pack_color for B4G4R4A4
Looks good to me Marek -- good catch.
Keith
On Thu, 2010-09-23 at 17:42 -0700, Marek Olšák wrote:
NOTE: This is a candidate for the 7.9 branch.
---
src/gallium/auxiliary/util/u_pack_color.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_pack_color.h
b/src/gallium/auxiliary/util/u_pack_color.h
index aae8b8b..c90b0fd 100644
--- a/src/gallium/auxiliary/util/u_pack_color.h
+++ b/src/gallium/auxiliary/util/u_pack_color.h
@@ -394,7 +394,7 @@ util_pack_color(const float rgba[4], enum pipe_format
format, union util_color *
return;
case PIPE_FORMAT_B4G4R4A4_UNORM:
{
- uc-ub = ((a 0xf0) 8) | ((r 0xf0) 4) | ((g 0xf0) 0)
| (b 4);
+ uc-us = ((a 0xf0) 8) | ((r 0xf0) 4) | ((g 0xf0) 0)
| (b 4);
}
return;
case PIPE_FORMAT_A8_UNORM:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: make makedepend an hard requirement
Currently makedepend is used by the Mesa Makefile-based build system, but not required. Unfortunately, not having it makes dependency resolution non-existent, which is a source of subtle bugs, and is a rarely tested configuration, since all Mesa developers likely have it installed. Furthermore some idioms require dependency resolution to work at all, such as making headers depend on generated files. --- configure.ac |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 2b8296d..e75224d 100644 --- a/configure.ac +++ b/configure.ac @@ -33,6 +33,10 @@ AC_CHECK_PROGS([MAKE], [gmake make]) AC_PATH_PROG([MKDEP], [makedepend]) AC_PATH_PROG([SED], [sed]) +if test x$MKDEP = x; then +AC_MSG_ERROR([makedepend is required to build Mesa]) +fi + dnl Our fallback install-sh is a symlink to minstall. Use the existing dnl configuration in that case. AC_PROG_INSTALL -- 1.7.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30333] DXT compressed SRGB textures cause assert failure
https://bugs.freedesktop.org/show_bug.cgi?id=30333 Brian Paul bri...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul bri...@vmware.com 2010-09-24 06:56:25 PDT --- Fixed with commit 9f7c8053e06663ba1f7b105f987052d9412d8fad -- 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] [PATCH] softpipe: allocate tile data on demand
On 09/24/2010 07:20 AM, Luca Barbieri wrote: Currently softpipe ends up allocating more than 200 MB of memory for each context due to the tile caches. Even worse, this memory is all explicitly cleared, which means that the kernel must actually back it with physical RAM right away. This change allocates tile memory on demand. The patch didn't apply cleanly to my tree so I hand-applied it. In any case, this change causes a ton of conformance failures. Several piglit tests in the general category also fail. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30353] building multilib mesa fails or bogus
https://bugs.freedesktop.org/show_bug.cgi?id=30353 --- Comment #2 from Sergey Kondakov virtuous...@gmail.com 2010-09-24 08:09:19 PDT --- so, it did built with '-j1' passed to make and with llvm support disabled. but it was fruitless - it just installed 32 bit binaries into supplied libdir. -- 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] [RFC] Mesa 7.9 release criteria
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like most of the bugs on the tracker have been fixed. The remaining bugs are: Bug 27831 - [regression] DynamicBranching3 does not render correctly: I've been looking into this, but I haven't made much progress. I don't know that it will get fixed anytime soon. Bug 29162 - commit 3750ebd540510324ef5ada769537ae05309adadb breaks darwin build: There haven't been any updates on this bug in a couple months. Does anyone that builds on Darwin care? Bug 29626 - [swrast] glean glsl1 texture2D() regression: The issue here is that the optimizer isn't eliminating an assignment of the varying to a temporary. That temporary is used in the TEX instruction, and swrast doesn't know how to determine the partial derivatives of the temporary. It seems unlikely that this will get fixed soon. I'd like to have a 7.9 release candidate on Monday (9/27). Assuming there are no major issues, I'd like to have a final release on the following Monday (10/4). Does that work for people? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyczwAACgkQX1gOwKyEAw/u2ACfUKvnPIDw7Wxcq1Z4pFu8h7q5 A4sAniA/QjEUtVSpDmyJ6NZee4NPElU1 =Nhr3 -END PGP SIGNATURE- ___ 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 6:15 AM, Dave Airlie airl...@gmail.com wrote: On Wed, Sep 22, 2010 at 7:50 PM, Keith Whitwell keith.whitw...@gmail.com wrote: On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie airl...@gmail.com 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. The z and stencil buffers are stored independently. Z24 buffers are not packed, they are stored using 32 bits. Alex Thanks, Dave. ___ 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] [PATCH] softpipe: allocate tile data on demand (v2)
Changes in v2:
- Invalidate last_tile_addr on any change, fixing regressions
- Correct coding style
Currently softpipe ends up allocating more than 200 MB of memory
for each context due to the tile caches.
Even worse, this memory is all explicitly cleared, which means that the
kernel must actually back it with physical RAM right away.
This change allocates tile memory on demand.
---
src/gallium/drivers/softpipe/sp_tile_cache.c | 145 +++---
src/gallium/drivers/softpipe/sp_tile_cache.h |9 +-
2 files changed, 112 insertions(+), 42 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c
b/src/gallium/drivers/softpipe/sp_tile_cache.c
index bf33fd9..7ed1052 100644
--- a/src/gallium/drivers/softpipe/sp_tile_cache.c
+++ b/src/gallium/drivers/softpipe/sp_tile_cache.c
@@ -38,6 +38,8 @@
#include util/u_tile.h
#include sp_tile_cache.h
+static struct softpipe_cached_tile *
+sp_alloc_tile(struct softpipe_tile_cache *tc);
/**
@@ -94,9 +96,19 @@ sp_create_tile_cache( struct pipe_context *pipe )
if (tc) {
tc-pipe = pipe;
for (pos = 0; pos NUM_ENTRIES; pos++) {
- tc-entries[pos].addr.bits.invalid = 1;
+ tc-tile_addrs[pos].bits.invalid = 1;
+ }
+ tc-last_tile_addr.bits.invalid = 1;
+
+ /* this allocation allows us to guarantee that allocation
+ * failures are never fatal later
+ */
+ tc-tile = MALLOC_STRUCT( softpipe_cached_tile );
+ if (!tc-tile)
+ {
+ FREE(tc);
+ return NULL;
}
- tc-last_tile = tc-entries[0]; /* any tile */
/* XXX this code prevents valgrind warnings about use of uninitialized
* memory in programs that don't clear the surface before rendering.
@@ -120,7 +132,10 @@ sp_destroy_tile_cache(struct softpipe_tile_cache *tc)
for (pos = 0; pos NUM_ENTRIES; pos++) {
/*assert(tc-entries[pos].x 0);*/
+ FREE( tc-entries[pos] );
}
+ FREE( tc-tile );
+
if (tc-transfer) {
tc-pipe-transfer_destroy(tc-pipe, tc-transfer);
}
@@ -285,11 +300,14 @@ sp_tile_cache_flush_clear(struct softpipe_tile_cache *tc)
uint numCleared = 0;
assert(pt-resource);
+ if (!tc-tile)
+ tc-tile = sp_alloc_tile(tc);
+
/* clear the scratch tile to the clear value */
if (tc-depth_stencil) {
- clear_tile(tc-tile, pt-resource-format, tc-clear_val);
+ clear_tile(tc-tile, pt-resource-format, tc-clear_val);
} else {
- clear_tile_rgba(tc-tile, pt-resource-format, tc-clear_color);
+ clear_tile_rgba(tc-tile, pt-resource-format, tc-clear_color);
}
/* push the tile to all positions marked as clear */
@@ -303,12 +321,12 @@ sp_tile_cache_flush_clear(struct softpipe_tile_cache *tc)
pipe_put_tile_raw(tc-pipe,
pt,
x, y, TILE_SIZE, TILE_SIZE,
- tc-tile.data.any, 0/*STRIDE*/);
+ tc-tile-data.any, 0/*STRIDE*/);
}
else {
pipe_put_tile_rgba(tc-pipe, pt,
x, y, TILE_SIZE, TILE_SIZE,
- (float *) tc-tile.data.color);
+ (float *) tc-tile-data.color);
}
numCleared++;
}
@@ -323,6 +341,27 @@ sp_tile_cache_flush_clear(struct softpipe_tile_cache *tc)
#endif
}
+static void
+sp_flush_tile(struct softpipe_tile_cache* tc, unsigned pos)
+{
+ if (!tc-tile_addrs[pos].bits.invalid) {
+ if (tc-depth_stencil) {
+ pipe_put_tile_raw(tc-pipe, tc-transfer,
+ tc-tile_addrs[pos].bits.x * TILE_SIZE,
+ tc-tile_addrs[pos].bits.y * TILE_SIZE,
+ TILE_SIZE, TILE_SIZE,
+ tc-entries[pos]-data.depth32, 0/*STRIDE*/);
+ }
+ else {
+ pipe_put_tile_rgba(tc-pipe, tc-transfer,
+tc-tile_addrs[pos].bits.x * TILE_SIZE,
+tc-tile_addrs[pos].bits.y * TILE_SIZE,
+TILE_SIZE, TILE_SIZE,
+(float *) tc-entries[pos]-data.color);
+ }
+ tc-tile_addrs[pos].bits.invalid = 1; /* mark as empty */
+ }
+}
/**
* Flush the tile cache: write all dirty tiles back to the transfer.
@@ -337,28 +376,20 @@ sp_flush_tile_cache(struct softpipe_tile_cache *tc)
if (pt) {
/* caching a drawing transfer */
for (pos = 0; pos NUM_ENTRIES; pos++) {
- struct softpipe_cached_tile *tile = tc-entries + pos;
- if (!tile-addr.bits.invalid) {
-if (tc-depth_stencil) {
- pipe_put_tile_raw(tc-pipe, pt,
- tile-addr.bits.x * TILE_SIZE,
- tile-addr.bits.y * TILE_SIZE,
- TILE_SIZE, TILE_SIZE,
-
Re: [Mesa-dev] [PATCH] softpipe: allocate tile data on demand
In any case, this change causes a ton of conformance failures. Several piglit tests in the general category also fail. Yes, sorry, I actually run piglit, but twice on the same binary... The problem was that last_tile_addr must be invalidated on any change including flushes. This was automatic before since we stored it at last_tile-addr, but now needs to be done explicitly. I posted a new version that should actually not have regressions on piglit. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29789] TALLOC_CFLAGS not used properly
https://bugs.freedesktop.org/show_bug.cgi?id=29789 nobled nob...@dreamwidth.org changed: What|Removed |Added CC||nob...@dreamwidth.org --- Comment #6 from nobled nob...@dreamwidth.org 2010-09-24 12:46:34 PDT --- Where exactly does the build fail, though? The INCLUDES variable in src/glsl/Makefile should be covering this. -- 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] cflags mess with llvm builds
On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) It's still strange to have scons use --cppflags and autotools --cflags. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] classic driver cleanup: ChooseTexFormat
One of the uglier bits of the classic drivers, in my opinion, is the ChooseTexFormat hook. Most drivers are trying to get to a similar set of formats, and using similar fallbacks for unavailable formats. Worse, they need to cleverly choose formats based on the incoming type/format to avoid having to munge the data on the way in if possible, and everyone needs to work those out. So, rather than having each driver have these smarts, move it to the core. There are still some rough edges. There are not enough fallbacks yet to cover everything (see i810 for example), so drivers with a more restricted set of supported formats may need to add more lines to _mesa_choose_tex_format. Also, the endianness-dependent choice of formats in texmem.c and radeon's texturing isn't merged -- I knew I'd mess it up somehow if I did it on my own, so I'm leaving radeon for someone with big-endian to finish off. Any complaints, or should I go ahead and merge this? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] mga: Merge texformat fallbacks into core.
This drops the screen-depth-dependent texture formatting and
force-16-bits option. The (default) screen depth dependency of format
choice for unsized internal formats would have resulted in additional
banding on 16-bit screens since 32-bit textures would get truncated
down to 16 bits before dithering occurred.
---
src/mesa/drivers/dri/mga/mga_xmesa.c | 24 --
src/mesa/drivers/dri/mga/mgacontext.h |2 -
src/mesa/drivers/dri/mga/mgatex.c | 141 -
src/mesa/main/texformat.c | 31 ++-
4 files changed, 44 insertions(+), 154 deletions(-)
diff --git a/src/mesa/drivers/dri/mga/mga_xmesa.c
b/src/mesa/drivers/dri/mga/mga_xmesa.c
index 3a31dfb..eb7b44b 100644
--- a/src/mesa/drivers/dri/mga/mga_xmesa.c
+++ b/src/mesa/drivers/dri/mga/mga_xmesa.c
@@ -88,7 +88,6 @@ DRI_CONF_BEGIN
DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_0)
DRI_CONF_SECTION_END
DRI_CONF_SECTION_QUALITY
-DRI_CONF_TEXTURE_DEPTH(DRI_CONF_TEXTURE_DEPTH_FB)
DRI_CONF_COLOR_REDUCTION(DRI_CONF_COLOR_REDUCTION_DITHER)
DRI_CONF_SECTION_END
DRI_CONF_SECTION_SOFTWARE
@@ -99,7 +98,7 @@ DRI_CONF_BEGIN
DRI_CONF_NO_RAST(false)
DRI_CONF_SECTION_END
DRI_CONF_END;
-static const GLuint __driNConfigOptions = 6;
+static const GLuint __driNConfigOptions = 5;
#ifndef MGA_DEBUG
int MGA_DEBUG = 0;
@@ -527,6 +526,22 @@ mgaCreateContext( gl_api api,
GL_FALSE,
0 );
+ memset(ctx-texture_format_supported, 0,
+ sizeof(ctx-texture_format_supported));
+ ctx-texture_format_supported[MESA_FORMAT_ARGB] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_ARGB] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_ARGB1555] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_RGB565] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_CI8] = GL_TRUE;
+ if (MGA_IS_G400(mmesa)) {
+ ctx-texture_format_supported[MESA_FORMAT_I8] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_AL88] = GL_TRUE;
+
+ /* ctx-Extensions.MESA_ycbcr_texture */
+ ctx-texture_format_supported[MESA_FORMAT_YCBCR] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_YCBCR_REV] = GL_TRUE;
+ }
+
ctx-Const.MinLineWidth = 1.0;
ctx-Const.MinLineWidthAA = 1.0;
ctx-Const.MaxLineWidth = 10.0;
@@ -535,11 +550,6 @@ mgaCreateContext( gl_api api,
ctx-Const.MaxDrawBuffers = 1;
- mmesa-texture_depth = driQueryOptioni (mmesa-optionCache,
- texture_depth);
- if (mmesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_FB)
- mmesa-texture_depth = ( mesaVis-rgbBits = 24 ) ?
-DRI_CONF_TEXTURE_DEPTH_32 : DRI_CONF_TEXTURE_DEPTH_16;
mmesa-hw_stencil = mesaVis-stencilBits mesaVis-depthBits == 24;
switch (mesaVis-depthBits) {
diff --git a/src/mesa/drivers/dri/mga/mgacontext.h
b/src/mesa/drivers/dri/mga/mgacontext.h
index 4141565..fc52d27 100644
--- a/src/mesa/drivers/dri/mga/mgacontext.h
+++ b/src/mesa/drivers/dri/mga/mgacontext.h
@@ -199,8 +199,6 @@ struct mga_context_t {
/* Map GL texture units onto hardware.
*/
GLuint tmu_source[2];
-
- int texture_depth;
/* Manage fallbacks
*/
diff --git a/src/mesa/drivers/dri/mga/mgatex.c
b/src/mesa/drivers/dri/mga/mgatex.c
index ca3dd4b..977bf73 100644
--- a/src/mesa/drivers/dri/mga/mgatex.c
+++ b/src/mesa/drivers/dri/mga/mgatex.c
@@ -159,146 +159,6 @@ static void mgaSetTexBorderColor(mgaTextureObjectPtr t,
const GLfloat color[4])
t-setup.texbordercol = PACK_COLOR_(c[3], c[0], c[1], c[2] );
}
-
-static gl_format
-mgaChooseTextureFormat( GLcontext *ctx, GLint internalFormat,
- GLenum format, GLenum type )
-{
- mgaContextPtr mmesa = MGA_CONTEXT(ctx);
- const GLboolean do32bpt =
- ( mmesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_32 );
- const GLboolean force16bpt =
- ( mmesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_FORCE_16 );
- (void) format;
-
- switch ( internalFormat ) {
- case 4:
- case GL_RGBA:
- case GL_COMPRESSED_RGBA:
- switch ( type ) {
- case GL_UNSIGNED_INT_10_10_10_2:
- case GL_UNSIGNED_INT_2_10_10_10_REV:
-return do32bpt ? MESA_FORMAT_ARGB : MESA_FORMAT_ARGB1555;
- case GL_UNSIGNED_SHORT_4_4_4_4:
- case GL_UNSIGNED_SHORT_4_4_4_4_REV:
-return MESA_FORMAT_ARGB;
- case GL_UNSIGNED_SHORT_5_5_5_1:
- case GL_UNSIGNED_SHORT_1_5_5_5_REV:
-return MESA_FORMAT_ARGB1555;
- default:
- return do32bpt ? MESA_FORMAT_ARGB : MESA_FORMAT_ARGB;
- }
-
- case 3:
- case GL_RGB:
- case GL_COMPRESSED_RGB:
- switch ( type ) {
- case GL_UNSIGNED_SHORT_4_4_4_4:
- case GL_UNSIGNED_SHORT_4_4_4_4_REV:
-return MESA_FORMAT_ARGB;
- case GL_UNSIGNED_SHORT_5_5_5_1:
- case GL_UNSIGNED_SHORT_1_5_5_5_REV:
-return MESA_FORMAT_ARGB1555;
- case
[Mesa-dev] [PATCH 1/6] mesa: Make _mesa_choose_tex_format() choose formats out of a supported table.
Right now this is just tweaking the current code to look at the table.
Choosing actually supported formats will come later.
---
src/mesa/main/context.c |8 ++
src/mesa/main/mtypes.h|3 +
src/mesa/main/texformat.c | 235 +
3 files changed, 165 insertions(+), 81 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 7d6bfaa..8acd0d3 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -949,6 +949,14 @@ _mesa_initialize_context_for_api(GLcontext *ctx,
ctx-FragmentProgram._MaintainTexEnvProgram = GL_TRUE;
}
+ /* Mesa core handles all the formats that mesa core knows about.
+* Drivers will want to override this list with just the formats
+* they can handle, and confirm that appropriate fallbacks exist in
+* _mesa_choose_tex_format().
+*/
+ memset(ctx-texture_format_supported, GL_TRUE,
+ sizeof(ctx-texture_format_supported));
+
switch (ctx-API) {
case API_OPENGL:
/* Neutral tnl module stuff */
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index d7c5d28..3eff4eb 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -40,6 +40,7 @@
#include glapi/glapi.h
#include math/m_matrix.h /* GLmatrix */
#include main/simple_list.h /* struct simple_node */
+#include main/formats.h /* MESA_FORMAT_COUNT */
/* Shader stages. Note that these will become 5 with tessellation.
* These MUST have the same values as PIPE_SHADER_*
@@ -3173,6 +3174,8 @@ struct __GLcontextRec
/** software compression/decompression supported or not */
GLboolean Mesa_DXTn;
+ GLboolean texture_format_supported[MESA_FORMAT_COUNT];
+
/**
* Use dp4 (rather than mul/mad) instructions for position
* transformation?
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index b9271ef..1200ca5 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
@@ -37,6 +37,10 @@
#include texcompress.h
#include texformat.h
+#define RETURN_IF_SUPPORTED(f) do {\
+ if (ctx-texture_format_supported[f]) \
+ return f;\
+} while (0)
/**
* Choose an appropriate texture format given the format, type and
@@ -65,37 +69,47 @@ _mesa_choose_tex_format( GLcontext *ctx, GLint
internalFormat,
case 4:
case GL_RGBA:
case GL_RGBA8:
- return MESA_FORMAT_RGBA;
+RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA);
+break;
case GL_RGB5_A1:
- return MESA_FORMAT_ARGB1555;
+RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB1555);
+break;
case GL_RGBA2:
- return MESA_FORMAT_ARGB_REV; /* just to test another format*/
+ RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB_REV); /* just to test
another format*/
+break;
case GL_RGBA4:
- return MESA_FORMAT_ARGB;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB);
+break;
/* deep RGBA formats */
case GL_RGB10_A2:
case GL_RGBA12:
case GL_RGBA16:
- return MESA_FORMAT_RGBA_16;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_16);
+break;
/* shallow RGB formats */
case 3:
case GL_RGB:
case GL_RGB8:
- return MESA_FORMAT_RGB888;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_RGB888);
+break;
case GL_R3_G3_B2:
- return MESA_FORMAT_RGB332;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_RGB332);
+break;
case GL_RGB4:
- return MESA_FORMAT_RGB565_REV; /* just to test another format */
+ RETURN_IF_SUPPORTED(MESA_FORMAT_RGB565_REV); /* just to test another
format */
+break;
case GL_RGB5:
- return MESA_FORMAT_RGB565;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_RGB565);
+break;
/* deep RGB formats */
case GL_RGB10:
case GL_RGB12:
case GL_RGB16:
- return MESA_FORMAT_RGBA_16;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_RGBA_16);
+break;
/* Alpha formats */
case GL_ALPHA:
@@ -103,7 +117,8 @@ _mesa_choose_tex_format( GLcontext *ctx, GLint
internalFormat,
case GL_ALPHA12:
case GL_ALPHA16:
case GL_ALPHA8:
- return MESA_FORMAT_A8;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_A8);
+break;
/* Luminance formats */
case 1:
@@ -112,7 +127,8 @@ _mesa_choose_tex_format( GLcontext *ctx, GLint
internalFormat,
case GL_LUMINANCE12:
case GL_LUMINANCE16:
case GL_LUMINANCE8:
- return MESA_FORMAT_L8;
+ RETURN_IF_SUPPORTED(MESA_FORMAT_L8);
+break;
/* Luminance/Alpha formats */
case 2:
@@ -120,19 +136,22 @@ _mesa_choose_tex_format( GLcontext *ctx, GLint
internalFormat,
case GL_LUMINANCE4_ALPHA4:
case GL_LUMINANCE6_ALPHA2:
case GL_LUMINANCE8_ALPHA8:
- return MESA_FORMAT_AL88;
+
[Mesa-dev] [PATCH 4/6] r128: Merge texformat fallbacks into core.
This drops the texture format forcing like for mga.
---
src/mesa/drivers/dri/r128/r128_context.c | 17 +++--
src/mesa/drivers/dri/r128/r128_context.h |2 -
src/mesa/drivers/dri/r128/r128_screen.c |7 +-
src/mesa/drivers/dri/r128/r128_tex.c | 118 --
src/mesa/main/texformat.c|6 ++
5 files changed, 19 insertions(+), 131 deletions(-)
diff --git a/src/mesa/drivers/dri/r128/r128_context.c
b/src/mesa/drivers/dri/r128/r128_context.c
index 7860708..b5a6eff 100644
--- a/src/mesa/drivers/dri/r128/r128_context.c
+++ b/src/mesa/drivers/dri/r128/r128_context.c
@@ -175,12 +175,6 @@ GLboolean r128CreateContext( gl_api api,
driSetTextureSwapCounterLocation( rmesa-texture_heaps[i],
rmesa-c_textureSwaps );
}
- rmesa-texture_depth = driQueryOptioni (rmesa-optionCache,
- texture_depth);
- if (rmesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_FB)
- rmesa-texture_depth = ( r128scrn-cpp == 4 ) ?
-DRI_CONF_TEXTURE_DEPTH_32 : DRI_CONF_TEXTURE_DEPTH_16;
-
rmesa-RenderIndex = -1;/* Impossible value */
rmesa-vert_buf = NULL;
@@ -208,6 +202,17 @@ GLboolean r128CreateContext( gl_api api,
GL_FALSE,
0 );
+ memset(ctx-texture_format_supported, 0,
+ sizeof(ctx-texture_format_supported));
+ ctx-texture_format_supported[MESA_FORMAT_ARGB] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_ARGB] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_RGB565] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_CI8] = GL_TRUE;
+
+ /* ctx-Extensions.MESA_ycbcr_texture */
+ ctx-texture_format_supported[MESA_FORMAT_YCBCR] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_YCBCR_REV] = GL_TRUE;
+
/* No wide points.
*/
ctx-Const.MinPointSize = 1.0;
diff --git a/src/mesa/drivers/dri/r128/r128_context.h
b/src/mesa/drivers/dri/r128/r128_context.h
index 65ddb3b..2742daf 100644
--- a/src/mesa/drivers/dri/r128/r128_context.h
+++ b/src/mesa/drivers/dri/r128/r128_context.h
@@ -157,8 +157,6 @@ struct r128_context {
r128TexObjPtr CurrentTexObj[2];
- int texture_depth;
-
/* Fallback rasterization functions
*/
r128_point_func draw_point;
diff --git a/src/mesa/drivers/dri/r128/r128_screen.c
b/src/mesa/drivers/dri/r128/r128_screen.c
index 7626a15..15b6625 100644
--- a/src/mesa/drivers/dri/r128/r128_screen.c
+++ b/src/mesa/drivers/dri/r128/r128_screen.c
@@ -57,9 +57,6 @@ DRI_CONF_BEGIN
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_0)
DRI_CONF_SECTION_END
-DRI_CONF_SECTION_QUALITY
-DRI_CONF_TEXTURE_DEPTH(DRI_CONF_TEXTURE_DEPTH_FB)
-DRI_CONF_SECTION_END
DRI_CONF_SECTION_DEBUG
DRI_CONF_NO_RAST(false)
#if ENABLE_PERF_BOXES
@@ -68,9 +65,9 @@ DRI_CONF_BEGIN
DRI_CONF_SECTION_END
DRI_CONF_END;
#if ENABLE_PERF_BOXES
-static const GLuint __driNConfigOptions = 4;
-#else
static const GLuint __driNConfigOptions = 3;
+#else
+static const GLuint __driNConfigOptions = 2;
#endif
#if 1
diff --git a/src/mesa/drivers/dri/r128/r128_tex.c
b/src/mesa/drivers/dri/r128/r128_tex.c
index b5a19b5..ac989aa 100644
--- a/src/mesa/drivers/dri/r128/r128_tex.c
+++ b/src/mesa/drivers/dri/r128/r128_tex.c
@@ -171,123 +171,6 @@ static r128TexObjPtr r128AllocTexObj( struct
gl_texture_object *texObj )
return t;
}
-
-/* Called by the _mesa_store_teximage[123]d() functions. */
-static gl_format
-r128ChooseTextureFormat( GLcontext *ctx, GLint internalFormat,
- GLenum format, GLenum type )
-{
- r128ContextPtr rmesa = R128_CONTEXT(ctx);
- const GLboolean do32bpt =
- ( rmesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_32 );
- const GLboolean force16bpt =
- ( rmesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_FORCE_16 );
- (void) format;
- (void) type;
-
- switch ( internalFormat ) {
- /* non-sized formats with alpha */
- case GL_INTENSITY:
- case GL_COMPRESSED_INTENSITY:
- case GL_ALPHA:
- case GL_COMPRESSED_ALPHA:
- case 2:
- case GL_LUMINANCE_ALPHA:
- case GL_COMPRESSED_LUMINANCE_ALPHA:
- case 4:
- case GL_RGBA:
- case GL_COMPRESSED_RGBA:
- if (do32bpt)
- return _dri_texformat_argb;
- else
- return _dri_texformat_argb;
-
- /* 16-bit formats with alpha */
- case GL_INTENSITY4:
- case GL_ALPHA4:
- case GL_LUMINANCE4_ALPHA4:
- case GL_RGBA2:
- case GL_RGBA4:
- return _dri_texformat_argb;
-
- /* 32-bit formats with alpha */
- case GL_INTENSITY8:
- case GL_INTENSITY12:
- case GL_INTENSITY16:
- case GL_ALPHA8:
- case GL_ALPHA12:
- case GL_ALPHA16:
- case GL_LUMINANCE6_ALPHA2:
- case GL_LUMINANCE8_ALPHA8:
- case GL_LUMINANCE12_ALPHA4:
- case GL_LUMINANCE12_ALPHA12:
- case GL_LUMINANCE16_ALPHA16:
- case GL_RGB5_A1:
- case GL_RGBA8:
-
[Mesa-dev] [PATCH 6/6] sis: Move to using core ChooseTexFormat.
---
src/mesa/drivers/dri/sis/sis_context.c | 16
src/mesa/drivers/dri/sis/sis_screen.c |5 +-
src/mesa/drivers/dri/sis/sis_tex.c | 127
3 files changed, 17 insertions(+), 131 deletions(-)
diff --git a/src/mesa/drivers/dri/sis/sis_context.c
b/src/mesa/drivers/dri/sis/sis_context.c
index 85f26a0..6169d36 100644
--- a/src/mesa/drivers/dri/sis/sis_context.c
+++ b/src/mesa/drivers/dri/sis/sis_context.c
@@ -249,6 +249,22 @@ sisCreateContext( gl_api api,
ctx-Const.MaxTextureImageUnits = ctx-Const.MaxTextureUnits;
ctx-Const.MaxTextureCoordUnits = ctx-Const.MaxTextureUnits;
+ memset(ctx-texture_format_supported, 0,
+ sizeof(ctx-texture_format_supported));
+ ctx-texture_format_supported[MESA_FORMAT_ARGB] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_ARGB] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_ARGB1555] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_RGB565] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_RGB332] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_L8] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_A8] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_I8] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_AL88] = GL_TRUE;
+
+ /* ctx-Extensions.MESA_ycbcr_texture */
+ ctx-texture_format_supported[MESA_FORMAT_YCBCR] = GL_TRUE;
+ ctx-texture_format_supported[MESA_FORMAT_YCBCR_REV] = GL_TRUE;
+
/* Parse configuration files */
driParseConfigFiles (smesa-optionCache, sisScreen-optionCache,
sisScreen-driScreen-myNum, sis);
diff --git a/src/mesa/drivers/dri/sis/sis_screen.c
b/src/mesa/drivers/dri/sis/sis_screen.c
index 80fb455..a227506 100644
--- a/src/mesa/drivers/dri/sis/sis_screen.c
+++ b/src/mesa/drivers/dri/sis/sis_screen.c
@@ -51,15 +51,12 @@ DRI_CONF_OPT_END
PUBLIC const char __driConfigOptions[] =
DRI_CONF_BEGIN
- DRI_CONF_SECTION_QUALITY
- DRI_CONF_TEXTURE_DEPTH(DRI_CONF_TEXTURE_DEPTH_FB)
- DRI_CONF_SECTION_END
DRI_CONF_SECTION_DEBUG
SIS_AGP_DISABLE(true)
DRI_CONF_NO_RAST(false)
DRI_CONF_SECTION_END
DRI_CONF_END;
-static const GLuint __driNConfigOptions = 3;
+static const GLuint __driNConfigOptions = 2;
extern const struct dri_extension card_extensions[];
diff --git a/src/mesa/drivers/dri/sis/sis_tex.c
b/src/mesa/drivers/dri/sis/sis_tex.c
index 31709c3..e9a1c79 100644
--- a/src/mesa/drivers/dri/sis/sis_tex.c
+++ b/src/mesa/drivers/dri/sis/sis_tex.c
@@ -226,132 +226,6 @@ static GLboolean sisIsTextureResident( GLcontext * ctx,
return (texObj-DriverData != NULL);
}
-static gl_format
-sisChooseTextureFormat( GLcontext *ctx, GLint internalFormat,
- GLenum format, GLenum type )
-{
- sisContextPtr smesa = SIS_CONTEXT(ctx);
-
- const GLboolean do32bpt =
- (smesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_32);
- const GLboolean force16bpt =
- (smesa-texture_depth == DRI_CONF_TEXTURE_DEPTH_FORCE_16);
-
- switch ( internalFormat ) {
- case 4:
- case GL_RGBA:
- case GL_COMPRESSED_RGBA:
- switch ( type ) {
- case GL_UNSIGNED_INT_10_10_10_2:
- case GL_UNSIGNED_INT_2_10_10_10_REV:
-return do32bpt ? MESA_FORMAT_ARGB : MESA_FORMAT_ARGB1555;
- case GL_UNSIGNED_SHORT_4_4_4_4:
- case GL_UNSIGNED_SHORT_4_4_4_4_REV:
-return MESA_FORMAT_ARGB;
- case GL_UNSIGNED_SHORT_5_5_5_1:
- case GL_UNSIGNED_SHORT_1_5_5_5_REV:
-return MESA_FORMAT_ARGB1555;
- default:
- return do32bpt ? MESA_FORMAT_ARGB : MESA_FORMAT_ARGB;
- }
-
- case 3:
- case GL_RGB:
- case GL_COMPRESSED_RGB:
- switch ( type ) {
- case GL_UNSIGNED_SHORT_4_4_4_4:
- case GL_UNSIGNED_SHORT_4_4_4_4_REV:
-return MESA_FORMAT_ARGB;
- case GL_UNSIGNED_SHORT_5_5_5_1:
- case GL_UNSIGNED_SHORT_1_5_5_5_REV:
-return MESA_FORMAT_ARGB1555;
- case GL_UNSIGNED_SHORT_5_6_5:
- case GL_UNSIGNED_SHORT_5_6_5_REV:
-return MESA_FORMAT_RGB565;
- default:
- return do32bpt ? MESA_FORMAT_ARGB : MESA_FORMAT_RGB565;
- }
-
- case GL_RGBA8:
- case GL_RGBA12:
- case GL_RGBA16:
- return !force16bpt ?
- MESA_FORMAT_ARGB : MESA_FORMAT_ARGB;
-
- case GL_RGB10_A2:
- return !force16bpt ?
- MESA_FORMAT_ARGB : MESA_FORMAT_ARGB1555;
-
- case GL_RGBA4:
- case GL_RGBA2:
- return MESA_FORMAT_ARGB;
-
- case GL_RGB5_A1:
- return MESA_FORMAT_ARGB1555;
-
- case GL_RGB8:
- case GL_RGB10:
- case GL_RGB12:
- case GL_RGB16:
- return !force16bpt ? MESA_FORMAT_ARGB : MESA_FORMAT_RGB565;
-
- case GL_RGB5:
- case GL_RGB4:
- return MESA_FORMAT_RGB565;
-
- case GL_R3_G3_B2:
- return MESA_FORMAT_RGB332;
-
- case GL_ALPHA:
- case GL_ALPHA4: /* FIXME: This could use its own texstore */
- case GL_ALPHA8:
-
[Mesa-dev] Current tinderbox regression (mesa, radeon)
http://tinderbox.x.org/builds/2010-09-24-0001/logs/libGL/#build radeon_drm_buffer.c:4:27: error: radeon_bo_gem.h: No such file or directory radeon_drm_buffer.c:5:27: error: radeon_cs_gem.h: No such file or directory In file included from radeon_drm_buffer.c:6: radeon_buffer.h:41:23: error: radeon_bo.h: No such file or directory radeon_buffer.h:42:23: error: radeon_cs.h: No such file or directory -- Chris Ball c...@laptop.org One Laptop Per Child ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
