[Bug 110229] Textures binded to framebuffer objects or images are not correctly updated.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110229

Daniel Stone <daniel at fooishbar.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTOURBUG
             Status|NEW                         |RESOLVED

--- Comment #19 from Daniel Stone <daniel at fooishbar.org> ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190401/39348248/attachment.html>