World of warcraft 1.12.1 crash on latest

[Altosk]

wow 1.12.1 crashes on start with latest ixit patches. also beyond good and evil crashes as well.

[axeldavy]

Weird, our beyond good and evil trace works.

Can you try to bisect find the bad commit for you ?

[axeldavy]

alternatively if you have the debug build, you can give the log and the location of the crash.

[Altosk]

https://www.sendspace.com/file/2us4xz wow 1.12.1 log

[Altosk]

https://www.sendspace.com/file/zll57j beyond good and evil log

[axeldavy]

Reading the log it crashes at about the same location, but I fail to see why. I didn't manage to reproduce with all my apps and my local traces, could it be a problem with your build ?

[Altosk]

st/nine: Use ff vertex shader when position_t is used removing this patch fixes the crashing for me in both games

[axeldavy]

Unfortunately I fail to see how the commit could cause the problem. Have you checked to have the last ixit git ?

Perhaps you can try: in nine_state.c,

Change the line

sampler_mask = state->vs ? state->vs->sampler_mask : 0;

to

sampler_mask = state->programmable_vs ? state->vs->sampler_mask : 0;

I don't expect it to fix it, but who knows..

[Altosk]

@axeldavy the game complains about not being able to "read" an address when using the original patch.

[Altosk]

i looked over the patch and i was wondering when does programmable_vs get set to false or true? I feel like i'm missing it?

[Altosk]

no go with that line changed

[axeldavy]

Someone reported Beyond good and evil works for him with ixit master. Perhaps your have some compilation bug ?

[axeldavy]

Besides, it is true state->programmable_vs doesn't get reset. Initially it is worth 0, as everything. We should reset it in some cases. However in the case of you logs, it crashes too soon to encounter any point where we should reset the value, so it is correctly initialized.

[Altosk]

this might be a bug in gcc 5.3.0 but i'm unable to test untill gentoo fixes their live build of llvm as it fails on applying a needed patch. using gcc 4.9.3 fails to build mesa because llvm is built with gcc 5.3.0?

[sarnex]

yeah abi broke between 4.9 and 5.3, so i'm guessing thats why mesa wont build

On Sat, Jan 9, 2016 at 10:15 AM, Altosk notifications@github.com wrote:

this might be a bug in gcc 5.3.0 but i'm unable to test untill gentoo fixes their live build of llvm as it fails on applying a needed patch. using gcc 4.9.3 fails to build mesa because llvm is built with gcc 5.3.0?

— Reply to this email directly or view it on GitHub https://github.com/iXit/Mesa-3D/issues/180#issuecomment-170251016.

[axeldavy]

As the problem is likely compiler bug, I intend to send the patches anyway for merging.

[Altosk]

@sarnex what useflags are u using to build mesa & wine? I've reinstalled gentoo and now its not running nine at all? On Jan 14, 2016 5:18 AM, "axeldavy" notifications@github.com wrote:

As the problem is likely compiler bug, I intend to send the patches anyway for merging.

— Reply to this email directly or view it on GitHub https://github.com/iXit/Mesa-3D/issues/180#issuecomment-171642108.

[sarnex]

@Altosk https://bpaste.net/show/b33efe3d98a1 https://bpaste.net/show/d5cc421b8f80

For wine I have -d3d9 because i have the staging+nine patch from slackner in /etc/patches

[Altosk]

@sarnex hm for some reason i'm not getting up to date ixit patches on my mesa build to apply(its doesnt error out)? does the patches folder need to be in /etc or /etc/portage? my bashrc in the portage folder is working because wine is showing staging + nine?

[sarnex]

@Altosk you need the ixit use flag with mesa from the wine-a-holics overlay and that should use the latest patch from https://github.com/NP-Hardass/mesa-d3d9-patches For wine, you put the staging+nine patch in /etc/portage/patches/app-emulation/wine/ninestaging.patch or whatever it's called

[Altosk]

hm something else is wrong then because I've done it all sorts of ways, i'm not getting support for r8g8b8 format from siro's patch which worked before.

[Altosk]

this was a compiler error closing