<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - Textures binded to framebuffer objects or images are not correctly updated." href="https://bugs.freedesktop.org/show_bug.cgi?id=110229#c20">Comment # 20</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - Textures binded to framebuffer objects or images are not correctly updated." href="https://bugs.freedesktop.org/show_bug.cgi?id=110229">bug 110229</a> from <a class="email" href="mailto:laurentduroisin@gmail.com" title="Laurent <laurentduroisin@gmail.com>"> Laurent</a> <pre>(In reply to Daniel Stone from <a href="show_bug.cgi?id=110229#c19">comment #19</a>) > (In reply to Laurent from <a href="show_bug.cgi?id=110229#c18">comment #18</a>) > > 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 ?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>