Direct Rendering Infrastructure

On Wednesday 26 April 2006 10:14, Rune Petersen wrote:
> Hi,
>
> Since the 12 of April there has been a change that causes Quake 3 and
> Doom 3 (demo)not to exit properly.
>
> Quake 3 locks up the system, and Doom 3 does a double fault.
>
> The suspect as I see it is:
> "Ensure all GART allocations are freed on context destruction"
>
> But I have yet to confirm it. If you are unable to confirm it, I'll try
> to track it down myself.

That patch was admittedly rather brute-force, but I've not had any issues w=
ith=20
it locally.

=2D ajax

Adam Jackson wrote:
> On Wednesday 26 April 2006 10:14, Rune Petersen wrote:
>> Hi,
>>
>> Since the 12 of April there has been a change that causes Quake 3 and
>> Doom 3 (demo)not to exit properly.
>>
>> Quake 3 locks up the system, and Doom 3 does a double fault.
>>
>> The suspect as I see it is:
>> "Ensure all GART allocations are freed on context destruction"
>>
>> But I have yet to confirm it. If you are unable to confirm it, I'll try
>> to track it down myself.
> 
> That patch was admittedly rather brute-force, but I've not had any issues with 
> it locally.

Turns out you're off the hook :) (for now)

The Quake 3 lockup is caused/triggered by a change done to Mesa (not 
r300) between 14 and 15 of April.

patch:
"Replace ctx->Const.MaxTextureUnits w/ 
ctx->Const.MaxTexture[Coord/Image]Units in various places."

looks like I need to join the Mesa mailing-list...


Rune Petersen

Rune Petersen wrote:
> Adam Jackson wrote:
> 
>> On Wednesday 26 April 2006 10:14, Rune Petersen wrote:
>>
>>> Hi,
>>>
>>> Since the 12 of April there has been a change that causes Quake 3 and
>>> Doom 3 (demo)not to exit properly.
>>>
>>> Quake 3 locks up the system, and Doom 3 does a double fault.
>>>
>>> The suspect as I see it is:
>>> "Ensure all GART allocations are freed on context destruction"
>>>
>>> But I have yet to confirm it. If you are unable to confirm it, I'll try
>>> to track it down myself.
>>
>>
>> That patch was admittedly rather brute-force, but I've not had any 
>> issues with it locally.
> 
> 
> Turns out you're off the hook :) (for now)
> 
> The Quake 3 lockup is caused/triggered by a change done to Mesa (not 
> r300) between 14 and 15 of April.
> 
> patch:
> "Replace ctx->Const.MaxTextureUnits w/ 
> ctx->Const.MaxTexture[Coord/Image]Units in various places."
> 
> looks like I need to join the Mesa mailing-list...

Do you have the MESA_DEBUG env var set?  That might give a hint.

I think the r300 driver is the only one that can have different values 
for GL_MAX_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_COORD_UNITS.  That 
might have something to do with it.

Looks like those values can be set in your .driconf file (though I'm 
not sure why that's a config option!).


Otherwise, here's the CVS check-in log.  You could try undoing the 
changes in one file at a time until you find the trouble:

   Revision      Changes    Path
   1.64          +4 -0      Mesa/src/mesa/main/matrix.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/main/matrix.c
   1.265         +3 -3      Mesa/src/mesa/main/mtypes.h
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/main/mtypes.h
   1.138         +114 -29   Mesa/src/mesa/main/texstate.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/main/texstate.c
   1.92          +4 -7      Mesa/src/mesa/swrast/s_context.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/swrast/s_context.c
   1.113         +2 -1      Mesa/src/mesa/swrast/s_span.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/swrast/s_span.c
   1.54          +3 -3      Mesa/src/mesa/tnl/t_array_api.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_array_api.c
   1.48          +1 -1      Mesa/src/mesa/tnl/t_vb_arbprogram.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_arbprogram.c
   1.9           +2 -2      Mesa/src/mesa/tnl/t_vb_arbshader.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_arbshader.c
   1.38          +1 -1      Mesa/src/mesa/tnl/t_vb_program.c
   http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_program.c


-Brian

I found the problem:
In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and 
MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h)

And there are no sanity-checks done on the values returned by the drivers.

Changing the defines to 16 makes everything work.

Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to 
src/mesa/main/config.h but a sanity-check fails (if commented out it 
lockups like before).

In the future it would be nice to have bounds checks on the Const.* values.


Rune Petersen

Brian Paul wrote:
> Rune Petersen wrote:
>> Adam Jackson wrote:
>>
>>> On Wednesday 26 April 2006 10:14, Rune Petersen wrote:
>>>
>>>> Hi,
>>>>
>>>> Since the 12 of April there has been a change that causes Quake 3 and
>>>> Doom 3 (demo)not to exit properly.
>>>>
>>>> Quake 3 locks up the system, and Doom 3 does a double fault.
>>>>
>>>> The suspect as I see it is:
>>>> "Ensure all GART allocations are freed on context destruction"
>>>>
>>>> But I have yet to confirm it. If you are unable to confirm it, I'll try
>>>> to track it down myself.
>>>
>>>
>>> That patch was admittedly rather brute-force, but I've not had any 
>>> issues with it locally.
>>
>>
>> Turns out you're off the hook :) (for now)
>>
>> The Quake 3 lockup is caused/triggered by a change done to Mesa (not 
>> r300) between 14 and 15 of April.
>>
>> patch:
>> "Replace ctx->Const.MaxTextureUnits w/ 
>> ctx->Const.MaxTexture[Coord/Image]Units in various places."
>>
>> looks like I need to join the Mesa mailing-list...
> 
> Do you have the MESA_DEBUG env var set?  That might give a hint.
> 
> I think the r300 driver is the only one that can have different values 
> for GL_MAX_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_COORD_UNITS.  That 
> might have something to do with it.
> 
> Looks like those values can be set in your .driconf file (though I'm not 
> sure why that's a config option!).
> 
> 
> Otherwise, here's the CVS check-in log.  You could try undoing the 
> changes in one file at a time until you find the trouble:
snip...

Rune Petersen wrote:
> I found the problem:
> In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and 
> MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h)
> 
> And there are no sanity-checks done on the values returned by the drivers.
> 
> Changing the defines to 16 makes everything work.
> 
> Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to 
> src/mesa/main/config.h but a sanity-check fails (if commented out it 
> lockups like before).
> 
> In the future it would be nice to have bounds checks on the Const.* values.

I've added a new function that does some sanity checks on the 
ctx->Const.* values the first time a context is bound.

As discussed a few days ago, we're presently limited to 8 texture 
image and coordinate units in core Mesa.

-Brian

Brian Paul wrote:
> Rune Petersen wrote:
>> I found the problem:
>> In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and 
>> MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h)
>>
>> And there are no sanity-checks done on the values returned by the 
>> drivers.
>>
>> Changing the defines to 16 makes everything work.
>>
>> Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to 
>> src/mesa/main/config.h but a sanity-check fails (if commented out it 
>> lockups like before).
>>
>> In the future it would be nice to have bounds checks on the Const.* 
>> values.
> 
> I've added a new function that does some sanity checks on the 
> ctx->Const.* values the first time a context is bound.

Great I hope it not a silent check...
> 
> As discussed a few days ago, we're presently limited to 8 texture image 
> and coordinate units in core Mesa.
>
I see in other words the restriction on MAX_TEXTURE_IMAGE_UNITS have to 
be there until splitting of the 2 units is completed in Mesa.
(managed to find a working mesa3d-dev archive)


Rune Petersen

Rune Petersen wrote:
> Brian Paul wrote:
> 
>> Rune Petersen wrote:
>>
>>> I found the problem:
>>> In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and 
>>> MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h)
>>>
>>> And there are no sanity-checks done on the values returned by the 
>>> drivers.
>>>
>>> Changing the defines to 16 makes everything work.
>>>
>>> Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to 
>>> src/mesa/main/config.h but a sanity-check fails (if commented out it 
>>> lockups like before).
>>>
>>> In the future it would be nice to have bounds checks on the Const.* 
>>> values.
>>
>>
>> I've added a new function that does some sanity checks on the 
>> ctx->Const.* values the first time a context is bound.
> 
> 
> Great I hope it not a silent check...

That wouldn't be much good, would it?


>> As discussed a few days ago, we're presently limited to 8 texture 
>> image and coordinate units in core Mesa.
>>
> I see in other words the restriction on MAX_TEXTURE_IMAGE_UNITS have to 
> be there until splitting of the 2 units is completed in Mesa.
> (managed to find a working mesa3d-dev archive)

The splitting is largely complete.  The larger issue has to do with 
the allocation and processing of vertex and fragment attributes.

-Brian

Brian Paul wrote:
> Rune Petersen wrote:
>> Brian Paul wrote:
>>
>>> Rune Petersen wrote:
>>>
>>>> I found the problem:
>>>> In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and 
>>>> MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h)
>>>>
>>>> And there are no sanity-checks done on the values returned by the 
>>>> drivers.
>>>>
>>>> Changing the defines to 16 makes everything work.
>>>>
>>>> Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to 
>>>> src/mesa/main/config.h but a sanity-check fails (if commented out it 
>>>> lockups like before).
>>>>
>>>> In the future it would be nice to have bounds checks on the Const.* 
>>>> values.
>>>
>>>
>>> I've added a new function that does some sanity checks on the 
>>> ctx->Const.* values the first time a context is bound.
>>
>>
>> Great I hope it not a silent check...
> 
> That wouldn't be much good, would it?

You could just clamp the value in the case of tex units to 8. I just 
wanted to make sure the user/devel is notified when the limits of Mesa 
is reached, so the either Mesa or the driver can be fixed.
> 
> 
>>> As discussed a few days ago, we're presently limited to 8 texture 
>>> image and coordinate units in core Mesa.
>>>
>> I see in other words the restriction on MAX_TEXTURE_IMAGE_UNITS have 
>> to be there until splitting of the 2 units is completed in Mesa.
>> (managed to find a working mesa3d-dev archive)
> 
> The splitting is largely complete.  The larger issue has to do with the 
> allocation and processing of vertex and fragment attributes.
Ok, thank you.


Rune Petersen

I build Quake3 from source and on my r300 Mesa CVS falls into indirect
rendering just after video mode initialization (tried both SDL GL and GLX
drivers). I thought that stencil is the reason, but disabling it didn't
help. There are no "r300 warnings" visible (there are in Cube, which also
disables hardware acceleration, but the reason in Cube is line smoothing).

--=20
Free Software - find interesting programs and change them
NetHack - meet interesting creatures, kill them and eat their bodies
Usenet - meet interesting people from all over the world and flame them
Decopter - unrealistic helicopter simulator, get it from
http://decopter.sf.net

Jacek Poplawski wrote:
> I build Quake3 from source and on my r300 Mesa CVS falls into indirect 
> rendering just after video mode initialization (tried both SDL GL and 
> GLX drivers). I thought that stencil is the reason, but disabling it 
> didn't help. There are no "r300 warnings" visible (there are in Cube, 
> which also disables hardware acceleration, but the reason in Cube is 
> line smoothing).

Does it fail to load libGL? I dunno what exact version of the game the 
source is, but it might miss the RTLD_GLOBAL flag when loading libGL.

Roland

I am sorry, I meant quake2, not quake3... :-o

On 5/29/06, Roland Scheidegger <rscheidegger_lists@...> wrote:
> Jacek Poplawski wrote:
> > I build Quake3 from source and on my r300 Mesa CVS falls into indirect
> > rendering just after video mode initialization (tried both SDL GL and
> > GLX drivers). I thought that stencil is the reason, but disabling it
> > didn't help. There are no "r300 warnings" visible (there are in Cube,
> > which also disables hardware acceleration, but the reason in Cube is
> > line smoothing).
>
> Does it fail to load libGL? I dunno what exact version of the game the
> source is, but it might miss the RTLD_GLOBAL flag when loading libGL.
>
> Roland
>


--=20
Free Software - find interesting programs and change them
NetHack - meet interesting creatures, kill them and eat their bodies
Usenet - meet interesting people from all over the world and flame them
Decopter - unrealistic helicopter simulator, get it from http://decopter.sf=
.net