Pioneer dev forum

The reason #2176 happens is because the LLVM shader compiler in MESA can't handle indirect addressing...
In #3719 however I cannot see any indirect addressing within the shader but it's still complaining about it and failing to build.

In fact looking at the old problem masque/tichy was having I can't see any indirect addressing in the eclipse code either.
So I wonder if the MESA shader compiler is falsely flagging it as using indirection, falling back to the TGSI compiler which then fails.

It works with the proprietary AMD drivers :/ Althoguh there I think the precision is lowered due to some odd distortion in the generated texture.

The Aras-P fork of glsl-optimizer doesn't think that there's ANY indirect addressing in the shader.

I don't suppose anyone knows a MESA driver dev with an R600 based GPU I could go poke with a stick?

<masque> Don't know... maybe on the mesa mailing lists http://www.mesa3d.org/lists.html or #dri-devel channel
<jameson> [ Mesa Mailing Lists ]
<masque> There are some name of people who contributed to r600 recently https://cgit.freedesktop.org/mesa/mesa/ ... rep&q=r600
<jameson> [ mesa/mesa - The Mesa 3D Graphics Library ]
<fluffyfreak> im just trying to put together a reduced size repoduction case
<fluffyfreak> no-one is going to want to download, build & run all of pioneer just for a little bug
<fluffyfreak> then those lists might be useful :)
<fluffyfreak> good that people are working on it though!

PS: please note that this a mix of brain-dump and tracking for these issues for me. I might delete the thread once/if the issues are all fixed.
PPS: I am having to reinstall Xubuntu due to numerous issues and will have to start again from scratch due to Xorg vs fglrx :(

I've nearly built a basic test-case so this can br reproduced by the MESA dev's.
Now of course I can't get the bug to happen in it :(

Now of course I can't get the bug to happen in it :(

Sounds like the first step to understanding what causes the bug.

Yeah the trouble is that I've now got it erm... "working" but have reduced it pretty far and it still works. Which means that it's some combination of the noise sampling and ... something.

EDIT: By "works" I mean, breaks, on Linux+AMDR600...

Started new job on Monday, progress stalled.

However I did find that reducing the number of octaves, and thus the number of iterations in the FBM loop, allowed it to work.
I think that it might be trying to loop-unroll the FBM loop since it's a fixed number and is overflowing the maximum allowed instructions. Cannot be sure of that though.

I have some things to try, such as passing in the octaves as a uniform to try and force it to be a loop rather than unrolling it, however I'm busy until Thursday (maybe Wednesday, for an hour]/i]) before I can take a look.

Andy

So this isn't ripe to report upstream to the mesa devs?

Good luck at the new job, btw!

Looks like it will still need reporting.
When you pass in the number of octaves, which defines how many times it will loop in the fbm, it simply fails to compile at all.

What I think was happening previously, and why it sometimes worked/failed, is that with a fixed number of iterations of the loop it could unroll the loop that many times ... so long as the number is fairly small.
Once it got a higher number of loop iterations (the octaves of the fbm) it must have tried to do it in a loop without unrolling it, and that fails.

This gives me a rather dubious way of working around it for our specific usage, I can set the number of octaves outside the shader as a #define, but I'm wondering how to report it and if it is indeed a bug as far as MESA dev's will be concerned.

Attempt at a workaround submitted in #3719 so it *should* work on AMD MESA R600 thingeymajig... too tired right now to test it on my own so off to bed.