[Mesa-dev] MESA and KOTOR

Sat Oct 7 12:58:29 UTC 2017

It doesn't even play in Windows to be honest.
Brian Paul is taking a look at it, he is a developer of apitrace I believe.

Anyway, a couple of clues that you might find useful:

  * Brian found these calls (these are the ones that make apitrace crash):
    3158346 glViewport(x = 0, y = -32, width = 8, height = -1)
    3158364 glViewport(x = 80, y = 22730, width = 640, height = 480)
    3159395 glViewport(x = 0, y = 768, width = 12624, height = 22502)
    They look suspicious as hell. I tried modifying
    src/mesa/main/viewport.c to clamp them to more reasonable values. It
    didn't fix the crashing in kotor, but I'm not an expert in how mesa
    works internally so maybe there are other source files involved and
    you can do something better
  * The crash is related to pbuffers, and it's an access violation. I
    took a look at src/gallium/state_trackers/wgl/stw_ext_pbuffer.c and
    from what I understand, it is implemented by drawing to an invisible
    window, right? Looking back at those strange values in glViewport,
    it makes me wonder if those seemingly random numbers could be some
    properties taken from those invisible windows (height, width, ...).
    Again, I'm no expert so I'll leave that to you to decide.
    And speaking of strange window manipulations, I noticed that when
    the game starts, the nvidia driver destroys and recreates the
    window, but mesa does not. Weird stuff, but it might be a clue.

I can give you a link to a copy of kotor with mesa if you want. I can't 
post it publicly here for obvious copyright reasons, but it's only 1.8gb 
if you want to give it a try.

Let me know what you think.

Thanks :)

Il 2017-10-07 14:46, Nicolai Hähnle ha scritto:
> Hi Federico,
>
> I finally got a chance to look at your trace. Unfortunately, it's not 
> easily usable: the trace basically fails to replay because it uses WGL 
> (the Windows GL system interface) instead of GLX.
>
> I can't really justify spending time on it because of that, sorry.
>
> If you do have time and interest to investigate, you could probably do 
> a lot of people a huge favor if you could modify apitrace in a way 
> that allows it to play WGL traces natively under Linux (e.g. by 
> translating the WGL functions into GLX ones).
>
> Cheers,
> Nicolai
>
> On 27.09.2017 11:21, Federico Dossena wrote:
>> Hi, did you get my previous email with the trace?
>>
>>
>> On 2017-09-26 14:11, Nicolai Hähnle wrote:
>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171007/58168544/attachment-0001.html>