Comme=
nt # 11
on bug 11022=
9
from Daniel Stone
(In reply to Laurent from comment #10)
> -You load the first instruction (the boot) tho t=
he GPU memory, it initialize
> the offset register to go to the next instruction but, there is no gua=
rantee
> that the CPU has loaded the next instruction before the GPU is pointin=
g to
> it.
>=20
> The solution is to load the last instruction first, and the first
> instruction (the boot) last so, you're guarantee that all the shader
> instructions are loaded before the GPU start to execute them.
I'm afraid that's not the problem. The drivers compile the whole shader, th=
en
copy it to memory, and the entire content is present before the shader stops
executing. This has been extensively battle-tested in many games, conforman=
ce
suites, computer-vision analysis, industrial-scale movie renders, etc.
The real answer is that maintaining these drivers is a lot of work, and the
people developing it cannot always drop everything to examine your source c=
ode
and debug a relatively complex application for you in the space of a few da=
ys.
GPU execution is very, very, different from CPU execution: in particular,
fragment shading is massively parallel (frequently within tiles). It may be
that the execution order is not what you expect, or the access to shared
variables is also not what you expect. It's hard to tell from the code, sin=
ce
the per-fragment linked-list approach you have is definitely ... novel.
I would try to begin by examining clearly what is going on at each step of =
your
fragment shader execution, so you can build a more precise theory of what is
going wrong. Good luck.