Comme=
nt # 14
on bug 11022=
9
from Laurent
(In reply to Laurent from comment #13)
> "I'm afraid that's not the problem. The dri=
vers compile the whole shader,
> then copy it to memory, and the entire content is present before the s=
hader
> stops executing. This has been extensively battle-tested in many games,
> conformance suites, computer-vision analysis, industrial-scale movie
> renders, etc."
>=20
> Yeah but the shader'll not stop if he's not launched, and you have to =
use
> some synchronisation mechanism to copy the content before the shader s=
tops.
>=20
>=20
> "The real answer is that maintaining these drivers is a lot of wo=
rk, and the
> people developing it cannot always drop everything to examine your sou=
rce
> code and debug a relatively complex application for you in the space o=
f a
> few days."
>=20
> Yes of course.
>=20
> "GPU execution is very, very, different from CPU execution: in pa=
rticular,
> fragment shading is massively parallel (frequently within tiles). It m=
ay be
> that the execution order is not what you expect, or the access to shar=
ed
> variables is also not what you expect. It's hard to tell from the code,
> since the per-fragment linked-list approach you have is definitely ...
> novel."
>=20
> Yeah so there are one thread per fragment and not per instruction.
> With the CPU you need mutex to avoid concurrent access, and I think tw=
o CPU
> thread cannot write/read to/from the memory at the same time, the GPU =
can
> because he use one micro controller per thread (if I'm not wrong) so y=
ou
> don't need to protect from concurrent access but you need to use an OIT
> mechanism in the driver (I think) because you don't know which thread'=
ll
> write to the memory first...
And (I've forgot), using mutex is slow so, normally we don't use them with =
the
GPU.