Comme=
nt # 19
on bug 11022=
9
from Daniel Stone
(In reply to Laurent from comment #18)
> Yeah so there are one thread per fragment and no=
t per instruction. With the CPU you need mutex to avoid concurrent access, =
and I think two 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 n=
ot wrong) so you 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 whic=
h thread'll write to the memory first...
Yes, you're right that the GPU executes code for multiple fragments
concurrently. The shader code has to know this and implement its own
concurrency protection. This is one of the (many) reasons why pretty much
no-one else uses a linked-list implementation in a fragment shader.
You also have the issue of wasted work: by the time a fragment shader execu=
tes,
you might as well just render the fragment, since so much work has already =
been
done to arrive at the per-fragment execution stage.
OpenGL and Vulkan already provide you many tools you can use to control how=
you
render, such as compute shaders with indirect dispatch, or even just using
stencil/depth tests (which you can also implement with a compute shader). U=
sing
compute shaders might also help you with your concurrency problems. I would
recommend looking into these common approaches first.
> I saw you wrote a GLSL compiler to translate GLS=
L source code to binary code
> but I think it's a waste of time because GLSL source code is very sim=
ilar
> to C source code so I think I'll use gcc compiler to compile GLSL sour=
ce
> code before sending it to the VRAM and executing it. (The only thing I=
'll
> have to do is translate GLSL code to C source code.
>=20
> I'll saving me a lot of time and in this way I think I'll be able to d=
ebug
> it more quickly.
When you run gcc, it produces code targeted for your CPU (x86-64 or Arm). g=
cc
cannot produce code which will be executed by a GPU. It also cannot parse G=
LSL:
even though GLSL visually looks a bit like C, it obviously executes very
differently.
I think you will very quickly discover that the amount of code in Mesa is n=
ot a
'waste of time', and is in fact all required to be able to run things on a =
GPU.
I'm going to close this report as 'NOTOURBUG', since it seems like the prob=
lems
you have in your code are caused by incorrectly using OpenGL, and could be
better handled through an OpenGL user support forum, or by following tutori=
als
(e.g. on depth/stencil or compute shaders).