[Mesa-dev] MESA and KOTOR

[Nicolai Hähnle]

On 26.09.2017 12:59, Federico Dossena wrote:
> The crash is in GLU, and I'm 99% sure that it has to do with the format 
> of that texture.

So how about a backtrace?

It would be really valuable to have a simple stand-alone reproduction.

Cheers,
Nicolai


> I saw a patch from Miklòs Màté a while ago that changed something in 
> src/mesa/state_tracker/st_atom_sampler.c to fix this (link: 
> https://patchwork.freedesktop.org/patch/68298/). It never made it to 
> master, and that function has changed quite a bit since his patch. I 
> don't really understand what it does since I don't know mesa very well, 
> do you know how I could do the same thing in the new st_convert_sampler 
> function?
> 
> Thanks
> 
> 
> Il 2017-09-26 12:56, Nicolai Hähnle ha scritto:
>> On 25.09.2017 18:50, Federico Dossena wrote:
>>> Hello everyone,
>>> you may remember that a few months ago I was trying to fix KOTOR to 
>>> work with Mesa to use the Gallium llvmpipe software renderer.
>>>
>>> Well, it's been a while and I'm happy to see that things are a bit 
>>> better with Mesa 17.2. The game still crashes, but we're closer to 
>>> fixing it.
>>>
>>> Here's what I found using 17.2.1:
>>> With frame buffer effects and soft shadows the game crashes at the 
>>> end of loading; the crash is inside a function that amongst other 
>>> things, generates mipmaps for a texture used in a pbuffer (function 
>>> at offset 2FB37D in my exe).
>>> The crash happens when gluBuild2DMipmaps is called, however doesn't 
>>> seem to be a null pointer like it was back in march: it's an access 
>>> violation alright but no longer a null pointer. So I think it's a 
>>> different, hopefully simpler, problem.
>>
>> So is it a crash in KOTOR, in glu, or in Mesa? If it's in one of the 
>> last two, then you should be able to compile both glu and Mesa from 
>> source with debugging info to help you narrow things down. A backtrace 
>> would be a good start.
>>
>> If it's in KOTOR itself, then I'm afraid we're probably not going to 
>> be a lot of help here...
>>
>> Cheers,
>> Nicolai
>>
>>>
>>> Back in march, Miklòs Màté suggested that changing the checks for the 
>>> pixel format could fix the problem, and he was right; without those 
>>> checks we definitely got a step closer to fixing it.
>>>
>>> My first thought was to just NOP the entire section that generates 
>>> mipmaps and a bit of code later that uses it. The game no longer 
>>> crashes, however it displays nothing, but I can hear it running in 
>>> background. So this is the last issue! We're almost there!
>>>
>>> Now, I'm bothering you again because I think that at this point it's 
>>> just a problem with the texture format used there. The call to 
>>> gluBuild2DMipmaps uses LuminanceAlpha' as texture format as well as 
>>> internal format (0x190a). I tried changing it to RGB and RGBA just to 
>>> try something, but that didn't work because I guess the texture was 
>>> already generated with another format.
>>>
>>> What could I do to investigate this further? And where should I look 
>>> inside Mesa if I wanted to say... force a specific texture format for 
>>> pbuffers?
>>>
>>> I feel that we're very close to fixing this. Your help would mean the 
>>> world to me and the whole KOTOR community.
>>>
>>> Thank you ;)
>>>
>>> P.S.
>>> This has nothing to do with mesa, but you should know that KOTOR is 
>>> slowly dieing. It is currently unplayable on Intel and AMD graphics, 
>>> and recent nVidia driver updates have introduced a glitch with 
>>> transparencies (it can be fixed, but still, no one can play KOTOR on 
>>> modern hardware properly and we have to keep old computers as 
>>> dedicated "shrines" for KOTOR, that's why I insist so much on Mesa)
>>>
>>>
>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>
>>
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.