Comme=
nt # 20
on bug 11022=
9
from Laurent
(In reply to Daniel Stone from comment #19)
> (In reply to Laurent from comment #18)
> > 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 two C=
PU thread cannot write/read to/from the memory at the same time, the GPU ca=
n because he use one micro controller per thread (if I'm not wrong) so you =
don't need to protect from concurrent access but you need to use an OIT mec=
hanism in the driver (I think) because you don't know which thread'll write=
to the memory first...
>=20
> 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 m=
uch
> no-one else uses a linked-list implementation in a fragment shader.
>=20
> You also have the issue of wasted work: by the time a fragment shader
> executes, you might as well just render the fragment, since so much wo=
rk has
> already been done to arrive at the per-fragment execution stage.
>=20
> OpenGL and Vulkan already provide you many tools you can use to contro=
l how
> you render, such as compute shaders with indirect dispatch, or even ju=
st
> using stencil/depth tests (which you can also implement with a compute
> shader). Using compute shaders might also help you with your concurren=
cy
> problems. I would recommend looking into these common approaches first.
>=20
> > I saw you wrote a GLSL compiler to translate GLSL source code to =
binary code
> > but I think it's a waste of time because GLSL source code is ver=
y similar
> > to C source code so I think I'll use gcc compiler to compile GLSL=
source
> > code before sending it to the VRAM and executing it. (The only th=
ing 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 debug
> > it more quickly.
>=20
> When you run gcc, it produces code targeted for your CPU (x86-64 or Ar=
m).
> gcc cannot produce code which will be executed by a GPU. It also cannot
> parse GLSL: even though GLSL visually looks a bit like C, it obviously
> executes very differently.
>=20
> I think you will very quickly discover that the amount of code in Mesa=
is
> not a 'waste of time', and is in fact all required to be able to run t=
hings
> on a GPU.
>=20
> I'm going to close this report as 'NOTOURBUG', since it seems like the
> problems 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 tutorials (e.g. on depth/stencil or compute shaders).
Ok if you think that's not your bug, do as you wish, but why are you writing
the driver source code in C if gcc cannot produce code which'll be executed=
on
a GPU ?