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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
