https://bugs.freedesktop.org/show_bug.cgi?id=110229
--- Comment #20 from Laurent <laurentduroi...@gmail.com> ---
(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 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 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 which 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
> executes, 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). Using 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 GLSL source code to binary code
> > but I think it's a waste of time because GLSL source code is very 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 thing I'll
> > have to do is translate GLSL code to C source code.
> >
> > I'll saving me a lot of time and in this way I think I'll be able to debug
> > it more quickly.
>
> When you run gcc, it produces code targeted for your CPU (x86-64 or Arm).
> 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.
>
> 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 things
> on a GPU.
>
> 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 ?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
