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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
