Summary: | [7.6] glxinfo: main/context.c:640: check_context_limits: Assertion failed | ||
---|---|---|---|
Product: | Mesa | Reporter: | Brice Goglin <brice.goglin> |
Component: | Drivers/DRI/r300 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | _deepfire |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550011 | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Brice Goglin
2009-10-06 22:15:50 UTC
Hopefully one of the Radeon developers can reproduce this. If the user could use gdb to get the values for ctx->Const.MaxTextureCoordUnits and ctx->Const.MaxTextureImageUnits that might be helpful. Brian, I cannot reproduce this here (and I really doubt it can happen unless you mess with your driconf settings - maybe the original reporter should check those), but is this assertion even correct? I agree with the assertions that MaxTextureUnits <= MaxTextureImageUnits MaxTextureUnits <= MaxTextureCoordUnits because a fixed function texture unit requires both the set of coordinates and the image. But I was under the impression that the whole point of the new MaxTextureImageUnits and MaxTextureCoordUnits was to decouple the two concepts which are no longer necessarily related in a programmable setting. In the fixed-function paths we use ctx->Const.MaxTextureCoordUnits all over the place. For fixed-function we have to have a texture image unit for each coord unit. I guess we could replace most occurances of ctx->Const.MaxTextureCoordUnits with ctx->Const.MaxTextureUnits (and remove the assertion) but that'd be a bit of work. Looking at the radeon code which sets these limits: ctx->Const.MaxTextureUnits = driQueryOptioni (&rmesa->radeon.optionCache, "texture_units"); ctx->Const.MaxTextureImageUnits = ctx->Const.MaxTextureUnits; ctx->Const.MaxTextureCoordUnits = ctx->Const.MaxTextureUnits; I don't see how the assertion would be failing. Can you try setting texture_units in your driconf and see what happens? BTW, shouldn't the driconf value be clamped to some limit? Good day, I'm the original reporter. I don't have ~/.drirc, nor /etc/drirc. I didn't install driconf before I saw it mentioned here. An additional detail lost in fight: setting LIBGL_ALWAYS_INDIRECT to 1 makes things work. Not sure it it's relevant, though. Here goes, anyway (in short: no useful data, perhaps): deepfire@betelheise:~$ LD_LIBRARY_PATH=/usr/lib/debug/usr/lib/ gdb glxinfo GNU gdb (GDB) 6.8.50.20090628-cvs-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... (no debugging symbols found) (gdb) run Starting program: /usr/bin/glxinfo (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] name of display: :0.0 glxinfo: main/context.c:640: check_context_limits: Assertion `ctx->Const.MaxTextureCoordUnits <= ctx->Const.MaxTextureImageUnits' failed. Program received signal SIGABRT, Aborted. 0x00007ffff75bed25 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007ffff75bed25 in raise () from /lib/libc.so.6 #1 0x00007ffff75c1de1 in abort () from /lib/libc.so.6 #2 0x00007ffff75b7f99 in __assert_fail () from /lib/libc.so.6 #3 0x00007ffff6b3c11b in check_context_limits (newCtx=0x61e350, drawBuffer=0x97b2d0, readBuffer=0x97b2d0) at main/context.c:640 #4 _mesa_make_current (newCtx=0x61e350, drawBuffer=0x97b2d0, readBuffer=0x97b2d0) at main/context.c:1419 #5 0x00007ffff6b1a79a in radeonMakeCurrent (driContextPriv=<value optimized out>, driDrawPriv=0x97b230, driReadPriv=0x97b230) at radeon_common_context.c:769 #6 0x00007ffff6af77ca in driBindContext (pcp=0x613c70, pdp=0x97b230, prp=0x97b230) at ../common/dri_util.c:206 #7 0x00007ffff7b87deb in MakeContextCurrent (dpy=0x606010, draw=23068676, read=23068676, gc=0x611590) at glxcurrent.c:378 #8 0x000000000040256f in ?? () #9 0x0000000000402d8e in ?? () #10 0x00007ffff75ab5c6 in __libc_start_main () from /lib/libc.so.6 #11 0x0000000000401369 in ?? () #12 0x00007fffffffe158 in ?? () #13 0x000000000000001c in ?? () #14 0x0000000000000001 in ?? () #15 0x00007fffffffe4b0 in ?? () #16 0x0000000000000000 in ?? () (gdb) f 3 #3 0x00007ffff6b3c11b in check_context_limits (newCtx=0x61e350, drawBuffer=0x97b2d0, readBuffer=0x97b2d0) at main/context.c:640 640 main/context.c: No such file or directory. in main/context.c (gdb) print ctx->Const.MaxTextureCoordUnits Cannot access memory at address 0x74c (gdb) print ctx->Const.MaxTextureImageUnits Cannot access memory at address 0x750 Can you build Mesa 7.6 in debug mode and re-run? Actually, r300_context.c does the following: ctx->Const.MaxTextureImageUnits = driQueryOptioni(&r300->radeon.optionCache, "texture_image_units"); ctx->Const.MaxTextureCoordUnits = driQueryOptioni(&r300->radeon.optionCache, "texture_coord_units"); ctx->Const.MaxTextureUnits = MIN2(ctx->Const.MaxTextureImageUnits, ctx->Const.MaxTextureCoordUnits); ... so I can see how the assertion could fail depending on the driconf settings. However, both options are set to default to 8 in radeon_screen.c, so this is still very odd. Reassigning to r300c. The classic r300 driver has been abandoned long ago. It was replaced by the Gallium driver r300g. If you have issues with r300g please file a new bug report with component Drivers/Gallium/r300 Thanks. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.