Bug 24365

Summary: [7.6] glxinfo: main/context.c:640: check_context_limits: Assertion failed
Product: Mesa Reporter: Brice Goglin <brice.goglin>
Component: Drivers/DRI/r300Assignee: 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
A user with a R423 and mesa 7.6 reports:

Simply running glxinfo produces following:

deepfire@betelheise:~$ glxinfo
name of display: :0.0
glxinfo: main/context.c:640: check_context_limits: Assertion `ctx->Const.MaxTextureCoordUnits <= ctx->Const.MaxTextureImageUnits' failed.
Aborted
Comment 1 Brian Paul 2009-10-07 07:24:21 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.
Comment 2 Nicolai Hähnle 2009-10-07 12:33:07 UTC
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.
Comment 3 Brian Paul 2009-10-07 13:23:38 UTC
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?

Comment 4 Samium Gromoff 2009-10-07 17:37:09 UTC
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
Comment 5 Brian Paul 2009-10-08 07:37:18 UTC
Can you build Mesa 7.6 in debug mode and re-run?
Comment 6 Nicolai Hähnle 2009-10-08 10:15:27 UTC
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.
Comment 7 Marek Olšák 2011-03-01 18:43:05 UTC
Reassigning to r300c.
Comment 8 Andreas Boll 2014-07-07 16:43:37 UTC
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.