[Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
I am trying to understand the s3tc init code as nv50 gallium has a problem with that. It looks like some drivers (r300g and llvmpipe) actually inits s3tc in two places : ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() Here is an extract of the backtrace calls while loading fgfs on llvmpipe : driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init driCreateContext -> st_create_context -> _mesa_create_context_for_api -> init_attrib_groups -> _mesa_init_texture_s3tc These two functions seem to do more or less the same job, and apparently, the classic mesa init is unused for a gallium driver. So I suppose that init is not necessary, but it happens because gallium and mesa are tightly tied together, and create context is handled similarly, but it shouldn't hurt ? Additionally r300g and llvmpipe added util_format_s3tc_init to their create_screen functions, and util/u_format_s3tc.c apparently contains all the functions that a gallium driver uses. So I suppose that nvfx and nv50 should do the same ? If that's correct, the patch below might not be completely wrong. On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry wrote: > flightgear now dies with : > Mesa warning: external dxt library not available: texstore_rgba_dxt3 > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' > failed. > > I don't really understand what these stubs are about, they were > introduced by following commit : > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > Author: José Fonseca > Date: Wed Apr 7 20:47:38 2010 +0100 > > util: Use stubs for the dynamically loaded S3TC functions. > > Loosely based on Luca Barbieri's commit > 52e9b990a192a9329006d5f7dd2ac222effea5a5. > > Looking at llvm and r300 code and trying to guess, I came up with the > following patch that allows flightgear to start again. But I don't > really understand that stuff so it could be wrong. > nvfx is probably affected as well. > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > b/src/gallium/drivers/nouveau/nouveau_screen.c > index 233a91a..a91b00b 100644 > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > @@ -5,6 +5,7 @@ > #include "util/u_memory.h" > #include "util/u_inlines.h" > #include "util/u_format.h" > +#include "util/u_format_s3tc.h" > > #include > #include > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, > struct nouveau_device *dev) > pscreen->fence_signalled = nouveau_screen_fence_signalled; > pscreen->fence_finish = nouveau_screen_fence_finish; > > + util_format_s3tc_init(); > + > return 0; > } > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > b/src/gallium/drivers/nv50/nv50_screen.c > index 2dd1042..0d74c90 100644 > --- a/src/gallium/drivers/nv50/nv50_screen.c > +++ b/src/gallium/drivers/nv50/nv50_screen.c > @@ -20,6 +20,7 @@ > * SOFTWARE. > */ > > +#include "util/u_format_s3tc.h" > #include "pipe/p_screen.h" > > #include "nv50_context.h" > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > case PIPE_FORMAT_A8_UNORM: > case PIPE_FORMAT_I8_UNORM: > case PIPE_FORMAT_L8A8_UNORM: > - case PIPE_FORMAT_DXT1_RGB: > - case PIPE_FORMAT_DXT1_RGBA: > - case PIPE_FORMAT_DXT3_RGBA: > - case PIPE_FORMAT_DXT5_RGBA: > case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > case PIPE_FORMAT_Z32_FLOAT: > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > case PIPE_FORMAT_R16G16_SNORM: > case PIPE_FORMAT_R16G16_UNORM: > return TRUE; > + case PIPE_FORMAT_DXT1_RGB: > + case PIPE_FORMAT_DXT1_RGBA: > + case PIPE_FORMAT_DXT3_RGBA: > + case PIPE_FORMAT_DXT5_RGBA: > + return util_format_s3tc_enabled; > default: > break; > } > -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] LLVM and udis86 dependencies
On 05/03/2010 11:36 AM, mesa3d-dev-requ...@lists.sourceforge.net wrote: > From: Francis Galiegue > Subject: [Mesa3d-dev] LLVM and udis86 dependencies > To: mesa3d-dev@lists.sourceforge.net > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > In the current HEAD, in configure.ac: > > > 1182-[enable_gallium=yes]) > 1183-if test "x$enable_gallium" = xyes; then > 1184-SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets" > 1185:AC_CHECK_HEADER([udis86.h], [HAS_UDIS86="yes"], > 1186-[HAS_UDIS86="no"]) > 1187-AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) > 1188-fi > -- > 1340- LLVM_LIBS="`$LLVM_CONFIG --libs jit interpreter nativecodegen > bitwriter` -lstdc++" > 1341- > 1342- if test "x$HAS_UDIS86" != xno; then > 1343: LLVM_LIBS="$LLVM_LIBS -ludis86" > 1344- DEFINES="$DEFINES -DHAVE_UDIS86" > 1345- fi > 1346- LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` > > > This means basically that the udis86 dependency is "automagic" if you > elect to build with LLVM support. > > I have a case here of a miscompiled udis86 (missing -fPIC, preventing > relocation) on a setup where LLVM was NOT compiled with udis86. > > Would it be possible to make the udis86 dependency optional (ie, > --with-udis86 option to ./configure)? LLVM 2.7 includes a disassembler of its own (libEnhancedDisassembly.so), could that one be used instead of udis86? Best regards, --Edwin -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] LLVM and udis86 dependencies
On Mon, 2010-05-03 at 01:42 -0700, Török Edwin wrote: > On 05/03/2010 11:36 AM, mesa3d-dev-requ...@lists.sourceforge.net wrote: > > From: Francis Galiegue > > Subject: [Mesa3d-dev] LLVM and udis86 dependencies > > To: mesa3d-dev@lists.sourceforge.net > > Message-ID: > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > In the current HEAD, in configure.ac: > > > > > > 1182-[enable_gallium=yes]) > > 1183-if test "x$enable_gallium" = xyes; then > > 1184-SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets" > > 1185:AC_CHECK_HEADER([udis86.h], [HAS_UDIS86="yes"], > > 1186-[HAS_UDIS86="no"]) > > 1187-AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) > > 1188-fi > > -- > > 1340- LLVM_LIBS="`$LLVM_CONFIG --libs jit interpreter nativecodegen > > bitwriter` -lstdc++" > > 1341- > > 1342- if test "x$HAS_UDIS86" != xno; then > > 1343: LLVM_LIBS="$LLVM_LIBS -ludis86" > > 1344- DEFINES="$DEFINES -DHAVE_UDIS86" > > 1345- fi > > 1346- LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` > > > > > > This means basically that the udis86 dependency is "automagic" if you > > elect to build with LLVM support. > > > > I have a case here of a miscompiled udis86 (missing -fPIC, preventing > > relocation) on a setup where LLVM was NOT compiled with udis86. > > > > Would it be possible to make the udis86 dependency optional (ie, > > --with-udis86 option to ./configure)? > > LLVM 2.7 includes a disassembler of its own (libEnhancedDisassembly.so), > could that one be used instead of udis86? Yes, that would be nice. udis86 seems a bit unmaintained a the moment. I've sent a few patches for some SSE4 opcodes to the maintainer and they weren't checked in yet. I thought about bundling its source in mesa, but when I saw news of LLVM's disassembler plans I thought it was better to wait. But I don't have time to look into this myself. If you don't have time either then a simple patch to make udis86 optional should be good enough for now. Jose -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: > I am trying to understand the s3tc init code as nv50 gallium has a > problem with that. > > It looks like some drivers (r300g and llvmpipe) actually inits s3tc in > two places : > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() > ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() > > Here is an extract of the backtrace calls while loading fgfs on llvmpipe : > driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init > driCreateContext -> st_create_context -> _mesa_create_context_for_api > -> init_attrib_groups -> _mesa_init_texture_s3tc > > These two functions seem to do more or less the same job, and > apparently, the classic mesa init is unused for a gallium driver. > So I suppose that init is not necessary, but it happens because > gallium and mesa are tightly tied together, and create context is > handled similarly, but it shouldn't hurt ? Both inits are necessary. The same .so is used for both paths, but given that gallium and mesa do not depend on each other that's the way to do it. Gallium and mesa also have seperate format translation functions. At least until we start factoring code into a separate library. (I said I'd do it, but stuff came up and I couldn't do when I thought, and I don't know when I'll be able to do it...) > Additionally r300g and llvmpipe added util_format_s3tc_init to their > create_screen functions, and util/u_format_s3tc.c apparently contains > all the functions that a gallium driver uses. > So I suppose that nvfx and nv50 should do the same ? > > If that's correct, the patch below might not be completely wrong. > > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry > wrote: > > flightgear now dies with : > > Mesa warning: external dxt library not available: texstore_rgba_dxt3 > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' > > failed. > > > > I don't really understand what these stubs are about, they were > > introduced by following commit : > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > > Author: José Fonseca > > Date: Wed Apr 7 20:47:38 2010 +0100 > > > >util: Use stubs for the dynamically loaded S3TC functions. > > > >Loosely based on Luca Barbieri's commit > >52e9b990a192a9329006d5f7dd2ac222effea5a5. > > > > Looking at llvm and r300 code and trying to guess, I came up with the > > following patch that allows flightgear to start again. But I don't > > really understand that stuff so it could be wrong. > > nvfx is probably affected as well. > > > > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > > b/src/gallium/drivers/nouveau/nouveau_screen.c > > index 233a91a..a91b00b 100644 > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > > @@ -5,6 +5,7 @@ > > #include "util/u_memory.h" > > #include "util/u_inlines.h" > > #include "util/u_format.h" > > +#include "util/u_format_s3tc.h" > > > > #include > > #include > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, > > struct nouveau_device *dev) > >pscreen->fence_signalled = nouveau_screen_fence_signalled; > >pscreen->fence_finish = nouveau_screen_fence_finish; > > > > + util_format_s3tc_init(); > > + > >return 0; > > } > > > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > > b/src/gallium/drivers/nv50/nv50_screen.c > > index 2dd1042..0d74c90 100644 > > --- a/src/gallium/drivers/nv50/nv50_screen.c > > +++ b/src/gallium/drivers/nv50/nv50_screen.c > > @@ -20,6 +20,7 @@ > > * SOFTWARE. > > */ > > > > +#include "util/u_format_s3tc.h" > > #include "pipe/p_screen.h" > > > > #include "nv50_context.h" > > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen > > *pscreen, > >case PIPE_FORMAT_A8_UNORM: > >case PIPE_FORMAT_I8_UNORM: > >case PIPE_FORMAT_L8A8_UNORM: > > - case PIPE_FORMAT_DXT1_RGB: > > - case PIPE_FORMAT_DXT1_RGBA: > > - case PIPE_FORMAT_DXT3_RGBA: > > - case PIPE_FORMAT_DXT5_RGBA: > >case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > >case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > >case PIPE_FORMAT_Z32_FLOAT: > > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen > > *pscreen, > >case PIPE_FORMAT_R16G16_SNORM: > >case PIPE_FORMAT_R16G16_UNORM: > >return TRUE; > > + case PIPE_FORMAT_DXT1_RGB: > > + case PIPE_FORMAT_DXT1_RGBA: > > + case PIPE_FORMAT_DXT3_RGBA: > > + case PIPE_FORMAT_DXT5_RGBA: > > + return util_format_s3tc_enabled; > >default: > >break; > >} > > You should only advertise PIPE_FORMAT_DXT* for BIND_SAMPLER_VIEW, or you may end up in very weird paths. Same for
Re: [Mesa3d-dev] [Mesa-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák wrote: > On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky > wrote: >> >> This commit breaks compiz completely here on nvidia G50 (Geforce 8400M) >> Compiz shows dark screen. >> (Using nouveau drivers) >> >> Without this commit compiz works almost perfectly. >> >> The error messages from compiz: >> >> >> debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE >> debug_get_bool_option: DRAW_FSE = FALSE >> debug_get_bool_option: DRAW_NO_FSE = FALSE >> debug_get_bool_option: GALLIUM_DUMP_VS = FALSE >> Mesa: Mesa 7.9-devel DEBUG build May 1 2010 19:02:06 >> Mesa warning: software DXTn compression/decompression available >> debug_get_bool_option: MESA_MVP_DP4 = FALSE >> debug_get_flags_option: ST_DEBUG = 0x0 >> Mesa: User error: GL_OUT_OF_MEMORY in glTexImage >> compiz (cube) - Warn: Failed to load >> slide: /usr/share/gdm/themes/Human/ubuntu.png >> ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage > > The commit also causes surface_copy to be called with S3TC textures, > breaking loading of such textures in r300g. I am working on a fix for r300g > but I haven't expected to get such weird formats in surface_copy. > > FYI Maxim, please use mesa-...@lists.freedesktop.org instead. > > -Marek > This commit also causes piglit fbo-3d test to fail with both llvmpipe and nv50 gallium. http://img163.imageshack.us/img163/535/fbo3d.png -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
On Mon, 2010-05-03 at 05:18 -0700, Marek Olšák wrote: > On Mon, May 3, 2010 at 1:57 PM, José Fonseca > wrote: > On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: > > I am trying to understand the s3tc init code as nv50 gallium > has a > > problem with that. > > > > It looks like some drivers (r300g and llvmpipe) actually > inits s3tc in > > two places : > > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() > > ./src/gallium/auxiliary/util/u_format_s3tc.c > util_format_s3tc_init() > > > > Here is an extract of the backtrace calls while loading fgfs > on llvmpipe : > > driCreateScreen -> llvmpipe_create_screen -> > util_format_s3tc_init > > driCreateContext -> st_create_context -> > _mesa_create_context_for_api > > -> init_attrib_groups -> _mesa_init_texture_s3tc > > > > These two functions seem to do more or less the same job, > and > > apparently, the classic mesa init is unused for a gallium > driver. > > So I suppose that init is not necessary, but it happens > because > > gallium and mesa are tightly tied together, and create > context is > > handled similarly, but it shouldn't hurt ? > > > Both inits are necessary. The same .so is used for both paths, > but given > that gallium and mesa do not depend on each other that's the > way to do > it. Gallium and mesa also have seperate format translation > functions. > > At least until we start factoring code into a separate > library. (I said > I'd do it, but stuff came up and I couldn't do when I thought, > and I > don't know when I'll be able to do it...) > > > > Additionally r300g and llvmpipe added util_format_s3tc_init > to their > > create_screen functions, and util/u_format_s3tc.c apparently > contains > > all the functions that a gallium driver uses. > > So I suppose that nvfx and nv50 should do the same ? > > > > If that's correct, the patch below might not be completely > wrong. > > > > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry > > wrote: > > > flightgear now dies with : > > > Mesa warning: external dxt library not available: > texstore_rgba_dxt3 > > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: > Assertion `0' failed. > > > > > > I don't really understand what these stubs are about, they > were > > > introduced by following commit : > > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > > > Author: José Fonseca > > > Date: Wed Apr 7 20:47:38 2010 +0100 > > > > > >util: Use stubs for the dynamically loaded S3TC > functions. > > > > > >Loosely based on Luca Barbieri's commit > > >52e9b990a192a9329006d5f7dd2ac222effea5a5. > > > > > > Looking at llvm and r300 code and trying to guess, I came > up with the > > > following patch that allows flightgear to start again. But > I don't > > > really understand that stuff so it could be wrong. > > > nvfx is probably affected as well. > > > > > > > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > > > b/src/gallium/drivers/nouveau/nouveau_screen.c > > > index 233a91a..a91b00b 100644 > > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > > > @@ -5,6 +5,7 @@ > > > #include "util/u_memory.h" > > > #include "util/u_inlines.h" > > > #include "util/u_format.h" > > > +#include "util/u_format_s3tc.h" > > > > > > #include > > > #include > > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct > nouveau_screen *screen, > > > struct nouveau_device *dev) > > >pscreen->fence_signalled = > nouveau_screen_fence_signalled; > > >pscreen->fence_finish = > nouveau_screen_fence_finish; > > > > > > + util_format_s3tc_init(); > > > + > > >return 0; > > > } > > > > > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > > > b/src/gallium/drivers/nv50/nv50_screen.c > > > index 2dd1042..0d74c90 100644 > > > --- a/src/gallium/drivers/nv50/nv50_screen.c > > > +++ b/src/gallium/drivers/nv50/nv50_screen.c > > > @@ -20,6 +20,7 @@ > > > * SOFTWARE. > > > */ > > > > > > +#include "util/u_format_s3tc.h" > > > #include "pipe
Re: [Mesa3d-dev] LLVM and udis86 dependencies
On 05/03/2010 12:22 PM, José Fonseca wrote: > On Mon, 2010-05-03 at 01:42 -0700, Török Edwin wrote: >> On 05/03/2010 11:36 AM, mesa3d-dev-requ...@lists.sourceforge.net wrote: >>> From: Francis Galiegue >>> Subject: [Mesa3d-dev] LLVM and udis86 dependencies >>> To: mesa3d-dev@lists.sourceforge.net >>> Message-ID: >>> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> In the current HEAD, in configure.ac: >>> >>> >>> 1182-[enable_gallium=yes]) >>> 1183-if test "x$enable_gallium" = xyes; then >>> 1184-SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets" >>> 1185:AC_CHECK_HEADER([udis86.h], [HAS_UDIS86="yes"], >>> 1186-[HAS_UDIS86="no"]) >>> 1187-AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) >>> 1188-fi >>> -- >>> 1340- LLVM_LIBS="`$LLVM_CONFIG --libs jit interpreter nativecodegen >>> bitwriter` -lstdc++" >>> 1341- >>> 1342- if test "x$HAS_UDIS86" != xno; then >>> 1343: LLVM_LIBS="$LLVM_LIBS -ludis86" >>> 1344- DEFINES="$DEFINES -DHAVE_UDIS86" >>> 1345- fi >>> 1346- LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` >>> >>> >>> This means basically that the udis86 dependency is "automagic" if you >>> elect to build with LLVM support. >>> >>> I have a case here of a miscompiled udis86 (missing -fPIC, preventing >>> relocation) on a setup where LLVM was NOT compiled with udis86. >>> >>> Would it be possible to make the udis86 dependency optional (ie, >>> --with-udis86 option to ./configure)? >> >> LLVM 2.7 includes a disassembler of its own (libEnhancedDisassembly.so), >> could that one be used instead of udis86? > > Yes, that would be nice. > > udis86 seems a bit unmaintained a the moment. I've sent a few patches > for some SSE4 opcodes to the maintainer and they weren't checked in yet. > I thought about bundling its source in mesa, but when I saw news of > LLVM's disassembler plans I thought it was better to wait. > > But I don't have time to look into this myself. If you don't have time > either then a simple patch to make udis86 optional should be good enough > for now. Sounds good, make udis86 optional now, and when someone has time to write a patch for using llvm's disassembler then udis86 can be dropped completely. Best regards, --Edwin -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
On Mon, May 3, 2010 at 1:57 PM, José Fonseca wrote: > On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: > > I am trying to understand the s3tc init code as nv50 gallium has a > > problem with that. > > > > It looks like some drivers (r300g and llvmpipe) actually inits s3tc in > > two places : > > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() > > ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() > > > > Here is an extract of the backtrace calls while loading fgfs on llvmpipe > : > > driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init > > driCreateContext -> st_create_context -> _mesa_create_context_for_api > > -> init_attrib_groups -> _mesa_init_texture_s3tc > > > > These two functions seem to do more or less the same job, and > > apparently, the classic mesa init is unused for a gallium driver. > > So I suppose that init is not necessary, but it happens because > > gallium and mesa are tightly tied together, and create context is > > handled similarly, but it shouldn't hurt ? > > Both inits are necessary. The same .so is used for both paths, but given > that gallium and mesa do not depend on each other that's the way to do > it. Gallium and mesa also have seperate format translation functions. > > At least until we start factoring code into a separate library. (I said > I'd do it, but stuff came up and I couldn't do when I thought, and I > don't know when I'll be able to do it...) > > > Additionally r300g and llvmpipe added util_format_s3tc_init to their > > create_screen functions, and util/u_format_s3tc.c apparently contains > > all the functions that a gallium driver uses. > > So I suppose that nvfx and nv50 should do the same ? > > > > If that's correct, the patch below might not be completely wrong. > > > > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry > > wrote: > > > flightgear now dies with : > > > Mesa warning: external dxt library not available: texstore_rgba_dxt3 > > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' > failed. > > > > > > I don't really understand what these stubs are about, they were > > > introduced by following commit : > > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > > > Author: José Fonseca > > > Date: Wed Apr 7 20:47:38 2010 +0100 > > > > > >util: Use stubs for the dynamically loaded S3TC functions. > > > > > >Loosely based on Luca Barbieri's commit > > >52e9b990a192a9329006d5f7dd2ac222effea5a5. > > > > > > Looking at llvm and r300 code and trying to guess, I came up with the > > > following patch that allows flightgear to start again. But I don't > > > really understand that stuff so it could be wrong. > > > nvfx is probably affected as well. > > > > > > > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > > > b/src/gallium/drivers/nouveau/nouveau_screen.c > > > index 233a91a..a91b00b 100644 > > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > > > @@ -5,6 +5,7 @@ > > > #include "util/u_memory.h" > > > #include "util/u_inlines.h" > > > #include "util/u_format.h" > > > +#include "util/u_format_s3tc.h" > > > > > > #include > > > #include > > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, > > > struct nouveau_device *dev) > > >pscreen->fence_signalled = nouveau_screen_fence_signalled; > > >pscreen->fence_finish = nouveau_screen_fence_finish; > > > > > > + util_format_s3tc_init(); > > > + > > >return 0; > > > } > > > > > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > > > b/src/gallium/drivers/nv50/nv50_screen.c > > > index 2dd1042..0d74c90 100644 > > > --- a/src/gallium/drivers/nv50/nv50_screen.c > > > +++ b/src/gallium/drivers/nv50/nv50_screen.c > > > @@ -20,6 +20,7 @@ > > > * SOFTWARE. > > > */ > > > > > > +#include "util/u_format_s3tc.h" > > > #include "pipe/p_screen.h" > > > > > > #include "nv50_context.h" > > > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > > >case PIPE_FORMAT_A8_UNORM: > > >case PIPE_FORMAT_I8_UNORM: > > >case PIPE_FORMAT_L8A8_UNORM: > > > - case PIPE_FORMAT_DXT1_RGB: > > > - case PIPE_FORMAT_DXT1_RGBA: > > > - case PIPE_FORMAT_DXT3_RGBA: > > > - case PIPE_FORMAT_DXT5_RGBA: > > >case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > > >case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > > >case PIPE_FORMAT_Z32_FLOAT: > > > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > > >case PIPE_FORMAT_R16G16_SNORM: > > >case PIPE_FORMAT_R16G16_UNORM: > > >return TRUE; > > > + case PIPE_FORMAT_DXT1_RGB: > > > + case PIPE_FORMAT_DXT1_RGBA: > > > + case PIPE_FORMAT_DXT3_RGBA: > > > + case PIPE_FORMAT_DXT5_RGB
Re: [Mesa3d-dev] LLVM and udis86 dependencies
On Mon, May 3, 2010 at 3:03 PM, Török Edwin wrote: [...] > > Sounds good, make udis86 optional now, and when someone has time to > write a patch for using llvm's disassembler then udis86 can be dropped > completely. > Untested (I have disabled LLVM support since I have encountered these problems), but there is an llvm-config command, IIRC, similarly to pkg-config, which can tell us which LDFLAGS/CPPFLAGS to use. Why not use this command, if the only requirement for Mesa is LLVM and not udis86? -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
