Re: [Mesa-dev] [PATCH 1/2] Fix __glXInitializeVisualConfigFromTags's handling of unrecognized fbconfig tags.
On Sun, May 02, 2010 at 02:39:07AM -0700, Dave Airlie wrote: On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner aplatt...@nvidia.com wrote: __glXInitializeVisualConfigFromTags doesn't skip the payload of unrecognized tags. Instead, it treats the value as if it were the next tag, which can happen if the server's GLX extension is not Mesa's. For example, this falls down when NVIDIA sends a GLX_FLOAT_COMPONENTS_NV = 0 pair, causing __glXInitializeVisualConfigFromTags to bail out early. I've had a regression reported on irc from papillon81 with GLX_USE_GL and OpenSceneGraph bisected to this. The spec is pretty clear about the attribute format for protocol: (for visuals) The first 18 properties are ordered; the remaining properties consist of a property type and a property value. (for fbconfigs) The properties consist of a property type and a property value. You use __glXInitializeVisualConfigFromTags in glXChooseVisual, don't you? I think you need something like fbconfig_style_tags bp++; Or I guess you could just hope that the server never sends GLX_USE_GL as a visual or FBconfig property. I'm guessing we need something like the attached. Dave. Signed-off-by: Aaron Plattner aplatt...@nvidia.com --- src/glx/glxext.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/glx/glxext.c b/src/glx/glxext.c index 5289354..6d6f89e 100644 --- a/src/glx/glxext.c +++ b/src/glx/glxext.c @@ -539,6 +539,8 @@ __glXInitializeVisualConfigFromTags(__GLcontextModes * config, int count, i = count; break; default: + /* Ignore the unrecognized tag's value */ + bp++; break; } } -- 1.6.3.3 ___ 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] cant compile with llvmpipe enabled
Hey. I get following error when try to compile mesa-git with --enable-gallium-llvm. g++ -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib/llvm -lpthread -lffi -ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format -Wl,--start-group -lXext -lXxf86vm -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -ldrm -lm -lpthread -ldl -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVMBitWriter -lLLVMX86CodeGen -lLLVMX86Info -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMInterpreter -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem -lstdc++ -Wl,--end-group ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_open': u_dl.c:(.text+0x21): undefined reference to `dlopen' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_get_proc_address': u_dl.c:(.text+0x50): undefined reference to `dlsym' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_close': u_dl.c:(.text+0x79): undefined reference to `dlclose' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_error': u_dl.c:(.text+0xa3): undefined reference to `dlerror' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar *)': (.text+0x32): undefined reference to `dlopen' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar *)': (.text+0x8a): undefined reference to `dlerror' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(char const*)': (.text+0x1a2): undefined reference to `dlsym' /usr/lib/llvm/libLLVMSystem.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x74): undefined reference to `dladdr' /usr/lib/llvm/libLLVMSystem.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x1ea): undefined reference to `dladdr' collect2: ld returned 1 exit status make[4]: *** [lp_test_format] Error 1 something is missing in my system or something ??? - Twoja sasiadka juz w to gra, a Ty na co czekasz? http://linkint.pl/f26af ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cant compile with llvmpipe enabled
On Mon, May 3, 2010 at 12:52 PM, yaiba.kurog...@interia.pl wrote: Hey. I get following error when try to compile mesa-git with --enable-gallium-llvm. g++ -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib/llvm -lpthread -lffi -ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format -Wl,--start-group -lXext -lXxf86vm -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -ldrm -lm -lpthread -ldl -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVMBitWriter -lLLVMX86CodeGen -lLLVMX86Info -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMInterpreter -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem -lstdc++ -Wl,--end-group [...] ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_open': u_dl.c:(.text+0x21): undefined reference to `dlopen' [...] Strange that you should have this error since you link against -ldl, where these (dl*()) functions are defined! Another strange thing is that -ldl appears _twice_ here, and once only after -L../../auxiliary, maybe that is the problem (I don't know the linker that well)? -- 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) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-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 mar...@gmail.com wrote: On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com 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-dev@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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): r300g: fix surface_copy for compressed formats
I am sure they're not advertised as supported render targets. You can find
the list of render target formats in r300_texture.c :
r300_translate_colorformat.
Yes the 3D blit is lossless for low precision formats. The thing is, as you
say, I'd have to change both the format and dimensions, i.e. pretty much
reinitializing all texture parameters with the same backing buffer. It did
not seem like the most important feature we need and stabilizing the driver
has a higher priority now. (BTW TA3D is a good test for these s3tc blits)
-Marek
On Mon, May 3, 2010 at 1:51 PM, José Fonseca jfons...@vmware.com wrote:
Also, does r300 advertise rendertarget support for compressed textures?
It probably does, and that's why you end up in this surface_copy path.
Jose
On Mon, 2010-05-03 at 04:47 -0700, José Fonseca wrote:
As long as the blit engine is not lossy, you could support everything by
using PIPE_FORMAT_I8_UNORM or something and adjusting dimensions.
Jose
On Sun, 2010-05-02 at 12:02 -0700, Marek Olšák wrote:
Module: Mesa
Branch: master
Commit: 3b2cf97c5c84c3a92f97f335b27f754aa42c5259
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=3b2cf97c5c84c3a92f97f335b27f754aa42c5259
Author: Marek Olšák mar...@gmail.com
Date: Sun May 2 17:19:03 2010 +0200
r300g: fix surface_copy for compressed formats
No accelerated blitting for these, it's too messy.
---
src/gallium/drivers/r300/r300_blit.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_blit.c
b/src/gallium/drivers/r300/r300_blit.c
index 928ad30..819d5e3 100644
--- a/src/gallium/drivers/r300/r300_blit.c
+++ b/src/gallium/drivers/r300/r300_blit.c
@@ -137,7 +137,8 @@ void r300_surface_copy(struct pipe_context* pipe,
if (!pipe-screen-is_format_supported(pipe-screen,
old_format,
src-texture-target,
PIPE_BIND_RENDER_TARGET |
- PIPE_BIND_SAMPLER_VIEW, 0))
{
+ PIPE_BIND_SAMPLER_VIEW, 0)
+util_format_description(old_format)-layout ==
UTIL_FORMAT_LAYOUT_PLAIN) {
switch (util_format_get_blocksize(old_format)) {
case 1:
new_format = PIPE_FORMAT_I8_UNORM;
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cant compile with llvmpipe enabled
On Mon, May 3, 2010 at 3:52 AM, yaiba.kurog...@interia.pl wrote: Hey. I get following error when try to compile mesa-git with --enable-gallium-llvm. g++ -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib/llvm -lpthread -lffi -ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format -Wl,--start-group -lXext -lXxf86vm -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -ldrm -lm -lpthread -ldl -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVMBitWriter -lLLVMX86CodeGen -lLLVMX86Info -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMInterpreter -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem -lstdc++ -Wl,--end-group ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_open': u_dl.c:(.text+0x21): undefined reference to `dlopen' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_get_proc_address': u_dl.c:(.text+0x50): undefined reference to `dlsym' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_close': u_dl.c:(.text+0x79): undefined reference to `dlclose' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_error': u_dl.c:(.text+0xa3): undefined reference to `dlerror' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar *)': (.text+0x32): undefined reference to `dlopen' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar *)': (.text+0x8a): undefined reference to `dlerror' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(char const*)': (.text+0x1a2): undefined reference to `dlsym' /usr/lib/llvm/libLLVMSystem.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x74): undefined reference to `dladdr' /usr/lib/llvm/libLLVMSystem.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x1ea): undefined reference to `dladdr' collect2: ld returned 1 exit status make[4]: *** [lp_test_format] Error 1 something is missing in my system or something ??? Does the problem go away when you build without -Wl,--as-needed? If so, it seems like the libraries need to be reordered so the linker doesn't throw out -ldl. Otherwise, I don't know. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Reorder LLVM passes, running mem2reg earlier.
This gives a ~30% shader optimization time improvement on blender.
Tested by comparing the dumped LLVM modules.
Current ordering:
time ~/llvm-git/obj/Release-Asserts/bin/opt l.bc -constprop -instcombine
-mem2reg -gvn -simplifycfg
real0m1.126s
user0m1.108s
sys 0m0.012s
With this patch:
time ~/llvm-git/obj/Release-Asserts/bin/opt l.bc -mem2reg -constprop
-instcombine -gvn -simplifycfg
real0m0.885s
user0m0.880s
sys 0m0.000s
The overall improvement in blender is ~15%.
Blender without the patch takes 1m13s:
edwin 5934 87.6 11.5 729440 458296 pts/5 SLl+ 17:35 1:13 blender
Blender with the patch takes 1m3s:
edwin 5726 94.2 11.2 716424 446168 pts/5 SLl+ 17:32 1:03 blender
It is still slow with the patch, but better (most of the optimization time is
taken up by GVN, see LLVM PR7023).
Signed-off-by: Török Edwin edwinto...@gmail.com
---
src/gallium/auxiliary/draw/draw_llvm.c |4 ++--
src/gallium/drivers/llvmpipe/lp_jit.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 2c23428..ea9b7c9 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -182,6 +182,8 @@ draw_llvm_create(struct draw_context *draw)
/* These are the passes currently listed in llvm-c/Transforms/Scalar.h,
* but there are more on SVN. */
/* TODO: Add more passes */
+ LLVMAddCFGSimplificationPass(llvm-pass);
+ LLVMAddPromoteMemoryToRegisterPass(llvm-pass);
LLVMAddConstantPropagationPass(llvm-pass);
if(util_cpu_caps.has_sse4_1) {
/* FIXME: There is a bug in this pass, whereby the combination of fptosi
@@ -190,9 +192,7 @@ draw_llvm_create(struct draw_context *draw)
*/
LLVMAddInstructionCombiningPass(llvm-pass);
}
- LLVMAddPromoteMemoryToRegisterPass(llvm-pass);
LLVMAddGVNPass(llvm-pass);
- LLVMAddCFGSimplificationPass(llvm-pass);
init_globals(llvm);
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c
b/src/gallium/drivers/llvmpipe/lp_jit.c
index 466a2f5..30e206a 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.c
+++ b/src/gallium/drivers/llvmpipe/lp_jit.c
@@ -185,6 +185,8 @@ lp_jit_screen_init(struct llvmpipe_screen *screen)
/* These are the passes currently listed in llvm-c/Transforms/Scalar.h,
* but there are more on SVN. */
/* TODO: Add more passes */
+ LLVMAddCFGSimplificationPass(screen-pass);
+ LLVMAddPromoteMemoryToRegisterPass(screen-pass);
LLVMAddConstantPropagationPass(screen-pass);
if(util_cpu_caps.has_sse4_1) {
/* FIXME: There is a bug in this pass, whereby the combination of
fptosi
@@ -193,9 +195,7 @@ lp_jit_screen_init(struct llvmpipe_screen *screen)
*/
LLVMAddInstructionCombiningPass(screen-pass);
}
- LLVMAddPromoteMemoryToRegisterPass(screen-pass);
LLVMAddGVNPass(screen-pass);
- LLVMAddCFGSimplificationPass(screen-pass);
}
lp_jit_init_globals(screen);
--
1.7.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test enhancement
On 02.05.2010 13:08, José Fonseca wrote: On Sun, 2010-05-02 at 02:36 -0700, Dave Airlie wrote: On Sun, May 2, 2010 at 7:30 PM, Jose Fonseca jfons...@vmware.com wrote: I read the extension and it is not crystal clear, but it seems to imply the swizzles are orthogonal to the format, and applied as the very last step before being used in a shader. That is, the semantics are the same of adding a swizzle instruction after a TEX opcode, regardless of the format. At least this is my interpretation of The values of the texture parameters TEXTURE_SWIZZLE_R_EXT, TEXTURE_SWIZZLE_G_EXT, TEXTURE_SWIZZLE_B_EXT, and TEXTURE_SWIZZLE_A_EXT, are applied after the swizzling described in Table 3.20 (p. 186). The swizzle parameter TEXTURE_SWIZZLE_R_EXT affects the first component of Cs as: BGRA extension does not specify additions to the 3.20 table though (it's against spec 1.1) so this is why the guess work. So my expectaction is that swizzling a BGRA with a .rgba swizzle will get bgra. It is also interesting the mention that the swizzle happens after texture compare mode. Actually, I mistyped, it is not texture compare mode, just depth texture mode. Yeah, this is all a bit confusing, but the depth texture comparison, if enabled, always uses the depth value from the texture, as you'd expect. This value then gets assigned to rgba/rgb/a depending on depth texture mode. So the texture swizzle happens after that - of course that means if you have specified a swizzle of . but your depth texture mode was alpha, you'll get a nice .... That is my interpretation as well, so in the r300 hw for example we use the texture swizzle to implement bgra vs rgba formats, I'd need to combine that with the incoming GL swizzle from the extension, but I'd really like to have some sort of test case to demonstrate it as I'm really not sure how ugly the combine swizzles function might end up. But it looks as if I need to write a direct to gallium test case to make sure I'm actually using things, mesa seems to block my attempts, though maybe with something like a PBO I can make mesa do it. I see now. It's probably worth to fix Mesa to memcpy user data unmodified as much as possible. grepping for GL_BGRA and PIPE_FORMAT_B8G8R8A8 in mesa shows some inconsistencies. Even for PBOs we say that PIPE_FORMAT_B8G8R8A8 is GL_RGBA and not GL_BGRA. A good way to go about this is centralize Gallium - GL and Gallium - Mesa format information in a big table. It means whenever a new format is added, there are a few places to modify. Anwyay this cleanup is not urgent, and is likely to cause regressions. FWIW, there's not only interaction with textures with different ordering (like bgra) but also those which are defined as rgb1 for instance. If you specify a swizzle of .aarr for instance, of course you'll get .11rr effectively. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
Jakob Bornecrantz wallbra...@gmail.com writes: A half backed idea would be to have to run a opt in slightly unstable branch, instead of going full multi-branch development model. Where bug-fixes can go in freely, small features can go in after a review of the changes by the module maintainer. What that means in practice is that driver developers can develop new features in their drivers but any new feature touching shared parts needs to get reviewed. The idea behind the branch is to be flexible if the situation change. So the branch might be restarted if the parties who are investing time in it agree to it. There could also be discussion if we want to base stable releases of it or master directly. Tho given the feel of the rest of the community stable will be based of master and slightly unstable will restart after that. Basically I will be running this branch either way, I'm just wondering if this is something that community has interest in it (given that the community are okay with me picking parts I like from stable branches into it and merging that back to master, with parts I'm interested in is core-mesa, st/mesa, st/dri, st/xorg and svga, also given that the change make sense)? We essentially bundle Mesa with the release of our software. This model sounds much more in line with the resources we have available for validation. It is definitely something we're interested in. We would need some type of tarball releases though. Ideally these would be official Mesa releases, but we could make do without that. -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Reorder LLVM passes, running mem2reg earlier.
On 2010-05-03 19:00, José Fonseca wrote: Török, Thanks. I didn't see as much improvement (most of the stuff I've been playing with has actually simple shaders), but I saw no regression so I've commited it. We have more benchmarks running continuously from git so once the commit goes through them we should have more data. Thanks. Also, do you know any good piece of documentation describing the good ordering of passes, or is it just trial/error? Look in include/llvm/Support/StandardPasses.h for the default ordering of -O1, -O2, -O3 Mem2reg is good to be run first because it reduces number of (alloca+load+store), and creates a new LLVM (SSA) value for them. It also enables further transforms to be smarter (most can't see accross a load/store). Now those orderings are for normal C programs, most of those optimizations may be of little benefit to shaders. Finding out which optimizers help shaders is a trial/error I think. Unfortunately LLVM doesn't have any -ffast-math-like optimizers, I think no CSE/reassoc is done on FP operations by default because that can lead to wrong results (due to rounding). Do the shaders need strict IEEE 754 math? Or can c+b+a be rewritten as a+b+c for example? Best regards, --Edwin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test enhancement
Jose Fonseca wrote: I read the extension and it is not crystal clear, but it seems to imply the swizzles are orthogonal to the format, and applied as the very last step before being used in a shader. That is, the semantics are the same of adding a swizzle instruction after a TEX opcode, regardless of the format. At least this is my interpretation of The values of the texture parameters TEXTURE_SWIZZLE_R_EXT, TEXTURE_SWIZZLE_G_EXT, TEXTURE_SWIZZLE_B_EXT, and TEXTURE_SWIZZLE_A_EXT, are applied after the swizzling described in Table 3.20 (p. 186). The swizzle parameter TEXTURE_SWIZZLE_R_EXT affects the first component of Cs as: Correct. BGRA extension does not specify additions to the 3.20 table though (it's against spec 1.1) so this is why the guess work. So my expectaction is that swizzling a BGRA with a .rgba swizzle will get bgra. Mmm, I don't think so. Regardless of the original user texture component ordering and regardless of the actually hardware texture format, when the shader calls texture2D(sampler, coord), for example, it _always_ returns a vector of (R, G, B, A) in that order. Similarly for ARB_vp/fp and fixed-function texture sampling. We'd have a miserable time writing shaders if we texture2D(sampler, coord) returned different component orderings depending on the actual texture format (which could vary from one system to another). An extenstion like GL_EXT_bgra is used to describe the incoming/user texture data to glTexImage2D, nothing about the internal/actual texture layout. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test enhancement
Dave Airlie wrote: In looking at adding EXT_texture_swizzle I'm a bit confused about what exactly should happen with BGRA textures, as on r300 we use the texture swizzling to do BGRA, so we would have some interaction at that point. To make sure we test for this I've made the following enhancments to the glean test (in piglit tree - but I'll resubmit against glean tree if correct). Can someone with a clue make sure this is a sane test, it passes against swrast.. The patch is sane. You're basically just defining the user texture either in RGBA vs. BGRA order in the two cases. This has no bearing on the internal/actual format of the texture or the results of sampling from the texture. However, I suggest: 1. use a better name for the 'format_pick' variable 2. add a comment for that parameter. 3. it's used as a boolean, so s/int/bool/ 4. fix up the indentation to match the rest of the file. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 2 util_format patches
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned by
util_format_name, it makes debug logs shorter. The second patch adds
util_format_is_plain.
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index fb6ade5..d851c31 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -332,10 +332,10 @@ util_format_name(enum pipe_format format)
assert(desc);
if (!desc) {
- return PIPE_FORMAT_???;
+ return ???;
}
- return desc-name;
+ return desc-name+12;
}
static INLINE boolean
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index d851c31..350b817 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -338,6 +338,18 @@ util_format_name(enum pipe_format format)
return desc-name+12;
}
+static INLINE boolean
+util_format_is_plain(enum pipe_format format)
+{
+ const struct util_format_description *desc =
util_format_description(format);
+
+ if (!format) {
+ return FALSE;
+ }
+
+ return desc-layout == UTIL_FORMAT_LAYOUT_PLAIN ? TRUE : FALSE;
+}
+
static INLINE boolean
util_format_is_s3tc(enum pipe_format format)
{
May I push them?
-Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test enhancement
On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote: Jose Fonseca wrote: I read the extension and it is not crystal clear, but it seems to imply the swizzles are orthogonal to the format, and applied as the very last step before being used in a shader. That is, the semantics are the same of adding a swizzle instruction after a TEX opcode, regardless of the format. At least this is my interpretation of The values of the texture parameters TEXTURE_SWIZZLE_R_EXT, TEXTURE_SWIZZLE_G_EXT, TEXTURE_SWIZZLE_B_EXT, and TEXTURE_SWIZZLE_A_EXT, are applied after the swizzling described in Table 3.20 (p. 186). The swizzle parameter TEXTURE_SWIZZLE_R_EXT affects the first component of Cs as: Correct. BGRA extension does not specify additions to the 3.20 table though (it's against spec 1.1) so this is why the guess work. So my expectaction is that swizzling a BGRA with a .rgba swizzle will get bgra. Mmm, I don't think so. Regardless of the original user texture component ordering and regardless of the actually hardware texture format, when the shader calls texture2D(sampler, coord), for example, it _always_ returns a vector of (R, G, B, A) in that order. Similarly for ARB_vp/fp and fixed-function texture sampling. We'd have a miserable time writing shaders if we texture2D(sampler, coord) returned different component orderings depending on the actual texture format (which could vary from one system to another). Actually, this is what I meant, but I see now I explained miserably! (@_@) What I meant is that if the user specifies a BGRA texture with the _bytes_: X Y Z W and we specify the TEXTURE_SWIZZLEs as (R, G, B, A) then we'd obtain W Z W X. in the shader (normalized by 1/255). What I mean is that the format swizzles have to be composed with the shader swizzles. An extenstion like GL_EXT_bgra is used to describe the incoming/user texture data to glTexImage2D, nothing about the internal/actual texture layout. Yes. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test enhancement
Dave Airlie wrote: On Sat, May 1, 2010 at 6:47 PM, Dave Airlie airl...@gmail.com wrote: In looking at adding EXT_texture_swizzle I'm a bit confused about what exactly should happen with BGRA textures, as on r300 we use the texture swizzling to do BGRA, so we would have some interaction at that point. To make sure we test for this I've made the following enhancments to the glean test (in piglit tree - but I'll resubmit against glean tree if correct). Can someone with a clue make sure this is a sane test, it passes against swrast.. Hmm on a second look inside mesa, it appears it never stores textures internally as BGRA, it always does a swizzle translate on the way in, so this test won't help me there, I'll have to think up something a bit more intricate to test this stuff. There's often texture swizzling involved in converting the user-provided image (GL_RGBA vs. GL_BGRA vs. GL_ABGR_EXT, etc) to the actual hardware texture format (MESA_FORMAT_RGBA, MESA_FORMAT_ARGB_REV, etc). BTW, people concerned with glTexImage() performance should do some experimentation with different source formats/types to find one that (hopefully) avoids swizzling and can just be memcpy'd. For swrast, Mesa prefers the MESA_FORMAT_RGBA format for slightly faster software rendering on some paths. If you want to force a different internal format for testing with swrast, just modify the _mesa_choose_tex_format() function in texformat.c. There's similar code for gallium in st_ChooseTextureFormat(). There's a glean test (packedPixels??) that exercises all the different glTexImage() format/type combinations if you're looking for something that will hit different texture formats. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 2 util_format patches
On Mon, 2010-05-03 at 10:25 -0700, Marek Olšák wrote:
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned
by util_format_name, it makes debug logs shorter. The second patch
adds util_format_is_plain.
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index fb6ade5..d851c31 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -332,10 +332,10 @@ util_format_name(enum pipe_format format)
assert(desc);
if (!desc) {
- return PIPE_FORMAT_???;
+ return ???;
}
- return desc-name;
+ return desc-name+12;
}
Just return desc-short_name. It's lower case so it's easier to read.
Also please modify src/gallium/drivers/trace/tr_dump_state.c to use the
full caps name, as retrace relies on it.
static INLINE boolean
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index d851c31..350b817 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -338,6 +338,18 @@ util_format_name(enum pipe_format format)
return desc-name+12;
}
+static INLINE boolean
+util_format_is_plain(enum pipe_format format)
+{
+ const struct util_format_description *desc =
util_format_description(format);
+
+ if (!format) {
+ return FALSE;
+ }
+
+ return desc-layout == UTIL_FORMAT_LAYOUT_PLAIN ? TRUE : FALSE;
+}
+
This is fine.
I have no problem with adding more such functions here, but for the
record, a better practice would be to call util_format_description once
and then do necessary operations with it. And typically there are
several. That is I'd rather see all inline functions in u_format.h
taking as argument the struct util_format_description *desc, expect
util_format_description().
static INLINE boolean
util_format_is_s3tc(enum pipe_format format)
{
May I push them?
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test enhancement
On Mon, 2010-05-03 at 10:29 -0700, José Fonseca wrote: On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote: Jose Fonseca wrote: I read the extension and it is not crystal clear, but it seems to imply the swizzles are orthogonal to the format, and applied as the very last step before being used in a shader. That is, the semantics are the same of adding a swizzle instruction after a TEX opcode, regardless of the format. At least this is my interpretation of The values of the texture parameters TEXTURE_SWIZZLE_R_EXT, TEXTURE_SWIZZLE_G_EXT, TEXTURE_SWIZZLE_B_EXT, and TEXTURE_SWIZZLE_A_EXT, are applied after the swizzling described in Table 3.20 (p. 186). The swizzle parameter TEXTURE_SWIZZLE_R_EXT affects the first component of Cs as: Correct. BGRA extension does not specify additions to the 3.20 table though (it's against spec 1.1) so this is why the guess work. So my expectaction is that swizzling a BGRA with a .rgba swizzle will get bgra. Mmm, I don't think so. Regardless of the original user texture component ordering and regardless of the actually hardware texture format, when the shader calls texture2D(sampler, coord), for example, it _always_ returns a vector of (R, G, B, A) in that order. Similarly for ARB_vp/fp and fixed-function texture sampling. We'd have a miserable time writing shaders if we texture2D(sampler, coord) returned different component orderings depending on the actual texture format (which could vary from one system to another). Actually, this is what I meant, but I see now I explained miserably! (@_@) What I meant is that if the user specifies a BGRA texture with the _bytes_: X Y Z W and we specify the TEXTURE_SWIZZLEs as (R, G, B, A) then we'd obtain W Z W X. I must be getting dyslexic. Z Y X W should be the answer. in the shader (normalized by 1/255). What I mean is that the format swizzles have to be composed with the shader swizzles. An extenstion like GL_EXT_bgra is used to describe the incoming/user texture data to glTexImage2D, nothing about the internal/actual texture layout. Yes. Jose ___ 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] 2 util_format patches
On Mon, 2010-05-03 at 10:42 -0700, Brian Paul wrote:
Marek Olšák wrote:
José,
the first patch removes the PIPE_FORMAT_ prefix in a string returned by
util_format_name, it makes debug logs shorter. The second patch adds
util_format_is_plain.
I'd prefer to keep the long format names.
I was recently burned by the Gallium docs omitting the prefixes on a
set of enums which I was grepping for.
With the full names it's easier to grep for format names and to
copypaste for debugging.
Fair enough. I really don't have a preference here.
Marek, if you really want to use short names in the drivers you maintain
then I'd suggest using the desc-short_name there (add a new
util_format_short_name()), but lets keep the long names elsewhere.
util_format_is_plain() is fine, but please put a comment on it to
describe what plain means to the newbie.
Yeah, I'm terrible with names. There's a description of what plain
format means in UTIL_FORMAT_LAYOUT_PLAIN's comment.
Jose
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index fb6ade5..d851c31 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -332,10 +332,10 @@ util_format_name(enum pipe_format format)
assert(desc);
if (!desc) {
- return PIPE_FORMAT_???;
+ return ???;
}
- return desc-name;
+ return desc-name+12;
}
static INLINE boolean
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index d851c31..350b817 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -338,6 +338,18 @@ util_format_name(enum pipe_format format)
return desc-name+12;
}
+static INLINE boolean
+util_format_is_plain(enum pipe_format format)
+{
+ const struct util_format_description *desc =
util_format_description(format);
+
+ if (!format) {
+ return FALSE;
+ }
+
+ return desc-layout == UTIL_FORMAT_LAYOUT_PLAIN ? TRUE : FALSE;
+}
+
static INLINE boolean
util_format_is_s3tc(enum pipe_format format)
{
May I push them?
-Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glapi: s/strcpy/strncpy/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vinson Lee wrote: Module: Mesa Branch: master Commit: 9446fd8f69564e09ffd0f28735a99c510f84bb62 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9446fd8f69564e09ffd0f28735a99c510f84bb62 Author: Vinson Lee v...@vmware.com Date: Sat May 1 15:34:47 2010 -0700 glapi: s/strcpy/strncpy/ --- src/mesa/glapi/glapi_getproc.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/glapi/glapi_getproc.c b/src/mesa/glapi/glapi_getproc.c index c73e8dd..ec96ab3 100644 --- a/src/mesa/glapi/glapi_getproc.c +++ b/src/mesa/glapi/glapi_getproc.c @@ -265,7 +265,8 @@ str_dup(const char *str) copy = (char*) malloc(strlen(str) + 1); if (!copy) return NULL; - strcpy(copy, str); + strncpy(copy, str, strlen(str)); + copy[strlen(str)] = '\0'; return copy; } Is this commit real, or a joke? April 1st was a long time ago. This change converts a call to strcpy to an open-coded version of strcpy using strncpy. NAK. This makes the code worse by any serious measure. Please revert. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvfE80ACgkQX1gOwKyEAw/KFwCfWYqkZxOsey8mDX0HKeJqQ1qr s5sAn1a9N6iLCS1PlcGPKCP3/TSDkfE2 =HBMA -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Monday 03 May 2010 14:17:30 Alex Deucher wrote: On Mon, May 3, 2010 at 2:09 PM, Brian Paul bri...@vmware.com wrote: I think it's worth exploring a policy of somehow tagging commits as candidates for back-porting to the stable branch so they can be some level of accounting and tracking. I don't think we need to work that out immediately though. On this point, it might be useful to update a cherry-pick wiki when you do cherry-pick commits back to the stable branch. That way when it comes time for the next stable point release, we can refer to the list to update the release notes (or even link to the page from the release notes for finer grained details). Thoughts? Would that actually gain us anything? I mean what would be the difference between that list and git log last_stable_releast..current_stable_branch ? I think what Brian meant was adding a magic tag to the commit message, e.g. BACKPORT, or FIX which I could make the Mesa3D commit hook pick out from the commits and either create a bugzilla entry for that commit, email the author after some time, add that commit sha1 hash to some list or do some other random action. But as Brian mentioned this is something we don't have to figure out right away but see what would actually be useful as folks start cherry picking to the stable branch. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Mon, May 3, 2010 at 2:26 PM, Zack Rusin za...@vmware.com wrote: On Monday 03 May 2010 14:17:30 Alex Deucher wrote: On Mon, May 3, 2010 at 2:09 PM, Brian Paul bri...@vmware.com wrote: I think it's worth exploring a policy of somehow tagging commits as candidates for back-porting to the stable branch so they can be some level of accounting and tracking. I don't think we need to work that out immediately though. On this point, it might be useful to update a cherry-pick wiki when you do cherry-pick commits back to the stable branch. That way when it comes time for the next stable point release, we can refer to the list to update the release notes (or even link to the page from the release notes for finer grained details). Thoughts? Would that actually gain us anything? I mean what would be the difference between that list and git log last_stable_releast..current_stable_branch ? I think what Brian meant was adding a magic tag to the commit message, e.g. BACKPORT, or FIX which I could make the Mesa3D commit hook pick out from the commits and either create a bugzilla entry for that commit, email the author after some time, add that commit sha1 hash to some list or do some other random action. But as Brian mentioned this is something we don't have to figure out right away but see what would actually be useful as folks start cherry picking to the stable branch. I guess it's just more of a manual variant of the same thing. Maybe we can add a mesa-stable address and you can add a cc in the commit like the kernel does. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures
On Mon, 2010-05-03 at 13:11 -0600, Brian Paul wrote: Xavier Chantry wrote: On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote: On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com 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-dev@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 Can you retest now? Nope, still same error. Best regards, Maxim Levitsky ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Convert mesa to automake/libtool
Dan Nicholson wrote: Brian, I'm putting forward this request completely understanding your position why you don't want automake and libtool in your project. However, I think that mesa has outgrown the static Makefiles approach for a number of reasons. For a project that's grown to the complexity of mesa, I believe you need something that is more flexible and robust than the current system can provide. Eric (and I think Corbin, too) has a branch adding automake and libtool to the mesa repo. http://cgit.freedesktop.org/~anholt/mesa/log/?h=automake I haven't looked at it in detail, but I know Eric knows what he's doing as he's maintained many of the autotooled xorg modules. Here are some of the pros and cons I see to making this change. Pros: * AM_CONDITIONAL provides a clean way to separate optional parts of the build. The way that optional components are handled right now is pretty fragile and basically amounts to having lists of subdirectories being correct in the config file. * For all mklib's simplicity, it is inconsistent between platforms, doesn't handle errors and provides only a scant amount of the features that libtool does. Libtool provides a robust and well tested means to generate libraries that handles nearly all the gory details about generating working binaries on many platforms. I don't think anyone working on mklib can claim to have the same type of knowledge about platforms and toolchains as the libtool developers. * Consistency in build commands for free from automake. Right now we have the compiling and linking commands repeated throughout the tree and they're typically out of sync. I've tried to keep them in sync before and it was a lot of effort. With automake all you really need to do is tell it the CFLAGS and LIBS to use and it'll take care of the rest. * Parallel make jobs just work. I've fixed so many of these race condition bugs, but they'd all just go away using automake. It has all the goop built in that people usually never think about. * Well defined distribution for tarballs. The top-level Makefile does the job, but automake can make this a lot easier and more robust. It would also be simple to handle the generated files while also requiring they be included in the tarball. * Fast source dependencies without external tools. The makedepend route works, but automake handles this in a faster, more robust and safer manner. We get a lot of people posting to the mailing list about build errors were the solution is make realclean. This would solve a lot of those issues. * Mindshare from xorg autotools. Many of the people here have and do work with the autotools via xorg, so it's not like this is a completely foreign beast. * Moves the burden of build tool knowledge onto someone else. I don't think anyone here wants to become an expert on compilers, linkers and ABI for multiple platforms. It become a lot easier when you toss things off to libtool where people are actually spending their time caring about them. * Extensive documentation available, unlike the current system which is pretty much ad hoc. http://www.gnu.org/software/autoconf/manual/autoconf.html http://www.gnu.org/software/automake/manual/automake.html http://www.gnu.org/software/libtool/manual/libtool.html http://sourceware.org/autobook/autobook/autobook.html Cons: * The abstracted nature of automake causes build debugging to be difficult. This requires you to train your brain not to look at the generated Makefile, but still it can be difficult. Fortunately, many of the build bugs we see today in Mesa would go away with automake. * Using libtool means that you can't quickly hack around a fix for some platform. Fortunately, libtool is a lot more stable these days on common platforms. * The maintainer (you) doesn't like it. Not much I can suggest here besides that it gets a lot easier the more you deal with it. And I'd be happy to help you out of any jams. For xorg, Peter Hutterer has asked me to solve a bunch of these problems, and I can't remember the last time we couldn't get something fixed. * Loss of the simple make $target usage. I understand you guys use these targets to quickly pop out a build. As a compromise, we could turn the configs into wrapper scripts that generated the autotools files and ran configure with appropriate arguments. For example, ./configs/linux-debug make. Or, since configure handles the platform parts, ./configs/debug or ./configs/osmesa. That's all I can think of. I'm sure we can continue to make the current system work, but I think integrating these tools would be a big improvement. Thanks for considering it. Hi Dan, Thanks for the thoughtfully worded pros cons. Your arguments are compelling and I can see value in a switch to automake. Just let me list my concerns. Some years ago someone converted Mesa to use autoconf/libtool and it was pretty awful. The libtool script wrapped every cc command and it slowed the build process considerably. Have you done
Re: [Mesa-dev] [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures
On Mon, May 3, 2010 at 9:11 PM, Brian Paul bri...@vmware.com wrote: This commit also causes piglit fbo-3d test to fail with both llvmpipe and nv50 gallium. http://img163.imageshack.us/img163/535/fbo3d.png Can you retest now? Yup, fbo-3d is back on both nv50 and llvmpipe/swrastg. Thanks ! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures
On Mon, 2010-05-03 at 15:18 -0600, Brian Paul wrote:
Maxim Levitsky wrote:
On Mon, 2010-05-03 at 13:11 -0600, Brian Paul wrote:
Xavier Chantry wrote:
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote:
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com
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-dev@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
Can you retest now?
Nope, still same error.
Both compiz and fbo-3d?
Didn't test fbo-3d, but compiz fails:
Breakpoint 1, _mesa_error (ctx=0x949690, error=1285, fmtString=0x734d8341
glTexImage) at main/imports.c:1005
1005{
(gdb) bt
#0 _mesa_error (ctx=0x949690, error=1285, fmtString=0x734d8341
glTexImage) at main/imports.c:1005
#1 0x73417504 in st_finalize_texture (ctx=0x949690, pipe=value
optimized out, tObj=0xcb1a80,
needFlush=value optimized out) at state_tracker/st_cb_texture.c:1920
#2 0x7340830a in finalize_textures (st=0x991f80) at
state_tracker/st_atom_texture.c:145
#3 0x734045d9 in st_validate_state (st=0x991f80) at
state_tracker/st_atom.c:167
#4 0x733d5b2a in st_draw_vbo (ctx=value optimized out,
arrays=0x9956c8, prims=value optimized out,
nr_prims=value optimized out, ib=0xcc49b0, index_bounds_valid=0 '\000',
min_index=0, max_index=15)
at state_tracker/st_draw.c:577
#5 0x733fcf84 in vbo_exec_DrawArrays (mode=7, start=0, count=value
optimized out)
at vbo/vbo_exec_array.c:525
#6 0x00427c9e in ?? ()
#7 0x00427afb in drawWindowTexture ()
#8 0x00427013 in drawWindow ()
#9 0x7fffef6bbd4f in ?? () from /usr/lib/compiz/libdecoration.so
#10 0x00426ef9 in paintWindow ()
#11 0x7fffefcd0988 in ?? () from /usr/lib/compiz/libmove.so
#12 0x7fffefacaa80 in ?? () from /usr/lib/compiz/libresize.so
#13 0x00428c3d in ?? ()
#14 0x004299b5 in paintOutput ()
#15 0x7fffefacaee0 in ?? () from /usr/lib/compiz/libresize.so
#16 0x00410b67 in paintScreen ()
#17 0x00412a35 in eventLoop ()
#18 0x0040d8e9 in main ()
(gdb) q
A debugging session is active.
Best regards,
Maxim Levitsky
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Convert mesa to automake/libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: The libtool script wrapped every cc command and it slowed the build process considerably. Have you done any before/after build time comparisons? I build a *lot*. This was traditionally the #1 complaint about autotools. Over the years a few iterations of fixes to this problem have percolated through the autotools community. Josh Triplett's dolt is one. My vague understanding is that the autotools maintainers have incorporated most of this directly into libtool. As far as I'm aware, the build time of a modern libtool project is within a standard deviation or two of a non-libtool project. Being able to trivially throw more CPUs at the compile has more than made up for the added overhead. distcc is the big win there... and working at a company that makes CPUs. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvfRNMACgkQX1gOwKyEAw+yfQCfcbVcxt/Jz4JfuKjWyzZ/ESAV k3AAn1zc5X8qNrnJHiBNBkEgKsH/Qzku =JCp9 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glapi: s/strcpy/strncpy/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: Vinson Lee wrote: Module: Mesa Branch: master Commit: 9446fd8f69564e09ffd0f28735a99c510f84bb62 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9446fd8f69564e09ffd0f28735a99c510f84bb62 Author: Vinson Lee v...@vmware.com Date: Sat May 1 15:34:47 2010 -0700 glapi: s/strcpy/strncpy/ --- src/mesa/glapi/glapi_getproc.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/glapi/glapi_getproc.c b/src/mesa/glapi/glapi_getproc.c index c73e8dd..ec96ab3 100644 --- a/src/mesa/glapi/glapi_getproc.c +++ b/src/mesa/glapi/glapi_getproc.c @@ -265,7 +265,8 @@ str_dup(const char *str) copy = (char*) malloc(strlen(str) + 1); if (!copy) return NULL; - strcpy(copy, str); + strncpy(copy, str, strlen(str)); + copy[strlen(str)] = '\0'; return copy; } It occurs to me that if the goal is to get rid of strcpy, presumably to silence a static analysis tool, the code could be changed to use memcpy: const size_t len = strlen(str) + 1; char *const copy = (char *) malloc(len); if (!copy) return NULL; memcpy(copy, str, len); return copy; My guess is that the code GCC actually generates for both versions (the original and the memcpy version) is pretty close to identical. At -O0, the memcpy version should be smaller / faster / have better stickers. In this particular case, why aren't we just using the system strdup? Are there really still platforms that don't include it? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvfR7EACgkQX1gOwKyEAw+UuACfVHv0dKlfLFZ/XVWCvgBOizMJ /mEAnR/dh4jNbRfkkBu+7acuw4fojj82 =pPIJ -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glapi: s/strcpy/strncpy/
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: Vinson Lee wrote: Module: Mesa Branch: master Commit: 9446fd8f69564e09ffd0f28735a99c510f84bb62 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9446fd8f69564e09ffd0f28735a99c510f84bb62 Author: Vinson Lee v...@vmware.com Date: Sat May 1 15:34:47 2010 -0700 glapi: s/strcpy/strncpy/ --- src/mesa/glapi/glapi_getproc.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/glapi/glapi_getproc.c b/src/mesa/glapi/glapi_getproc.c index c73e8dd..ec96ab3 100644 --- a/src/mesa/glapi/glapi_getproc.c +++ b/src/mesa/glapi/glapi_getproc.c @@ -265,7 +265,8 @@ str_dup(const char *str) copy = (char*) malloc(strlen(str) + 1); if (!copy) return NULL; - strcpy(copy, str); + strncpy(copy, str, strlen(str)); + copy[strlen(str)] = '\0'; return copy; } It occurs to me that if the goal is to get rid of strcpy, presumably to silence a static analysis tool, the code could be changed to use memcpy: const size_t len = strlen(str) + 1; char *const copy = (char *) malloc(len); if (!copy) return NULL; memcpy(copy, str, len); return copy; That looks good. My guess is that the code GCC actually generates for both versions (the original and the memcpy version) is pretty close to identical. At -O0, the memcpy version should be smaller / faster / have better stickers. In this particular case, why aren't we just using the system strdup? Are there really still platforms that don't include it? IIRC, Windows. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Re:cant compile with llvmpipe enabled
Ok. I removed -Wl,--as-needed and now compilation went smooth.However when I enable gles1 and gles2 and add es state tracker I got something like this: mklib: Making Linux shared library: libGL.so.1.2 mklib: Installing libGL.so.1.2 libGL.so.1 libGL.so in ../../lib make[2]: Opuszczenie katalogu `/usr/src/mesa-full/src/mesa-build/src/glx' make[2]: Wejście do katalogu `/usr/src/mesa-full/src/mesa-build/src/gles' rm -f depend touch depend /usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include -I/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include-fixed -I../../src/mesa/es/glapi/glapi- -I../../src/mesa ../../src/mesa/glapi/glapi.c ../../src/mesa/glapi/glapi_dispatch.c ../../src/mesa/glapi/glapi_entrypoint.c ../../src/mesa/glapi/glapi_execmem.c ../../src/mesa/glapi/glapi_getproc.c ../../src/mesa/glapi/glapi_nop.c ../../src/mesa/glapi/glthread.c \ /usr/bin/makedepend: warning: ../../src/mesa/glapi/glapi.c (reading ../../src/mesa/main/glheader.h, line 55): cannot find include file GL/internal/glcore.h not in GL/internal/glcore.h not in ../../src/mesa/main/GL/internal/glcore.h not in /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include/GL/internal/glcore.h not in /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include-fixed/GL/internal/glcore.h not in ../../src/mesa/es/glapi/glapi-/GL/internal/glcore.h not in ../../src/mesa/GL/internal/glcore.h not in /usr/include/GL/internal/glcore.h make[2]: Opuszczenie katalogu `/usr/src/mesa-full/src/mesa-build/src/gles' make[2]: Wejście do katalogu `/usr/src/mesa-full/src/mesa-build/src/gles' gcc -c -march=i686 -mtune=generic -O2 -pipe -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMESA_LLVM -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0207 -I../../src/mesa/es/glapi/glapi-es1 -I../../src/mesa -o es1-glapi_x86.o ../../src/mesa/es/glapi/glapi-es1/x86/glapi_x86.S gcc -c -march=i686 -mtune=generic -O2 -pipe -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMESA_LLVM -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0207 -I../../src/mesa/es/glapi/glapi-es1 -I../../src/mesa -o es1-glapi.o ../../src/mesa/glapi/glapi.c In file included from ../../src/mesa/glapi/glapi.c:57:0: ../../src/mesa/main/glheader.h:55:32: fatal error: GL/internal/glcore.h: No such file or directory compilation terminated. make[2]: *** [es1-glapi.o] Error 1 My PKGBUILD: (..)./autogen.sh --prefix=/usr \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --enable-glx-tls \ --with-dri-drivers=nouveau \ --enable-xcb \ --disable-egl \ --disable-glu \ --with-state-trackers=glx,dri,xorg,vega,es \ --disable-glw \ --enable-gles1 \ --enable-gles2 \ --enable-gallium \ --enable-gallium-llvm \ --disable-gallium-intel \ --disable-gallium-svga \ --disable-gallium-radeon \ --disable-gallium-nouveau || return 1 (...) How to solve this? -- Najlepsza wyszukiwarka tanich lotow! Sprawdz http://linkint.pl/f26b1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
