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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Mar 29 21:36:57 UTC 2019


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

--- Comment #13 from Laurent <laurentduroisin at gmail.com> ---
"I'm afraid that's not the problem. The drivers compile the whole shader, then
copy it to memory, and the entire content is present before the shader stops
executing. This has been extensively battle-tested in many games, conformance
suites, computer-vision analysis, industrial-scale movie renders, etc."

Yeah but the shader'll not stop if he's not launched, and you have to use some
synchronisation mechanism to copy the content before the shader stops.


"The real answer is that maintaining these drivers is a lot of work, and the
people developing it cannot always drop everything to examine your source code
and debug a relatively complex application for you in the space of a few days."

Yes of course.

"GPU execution is very, very, different from CPU execution: in particular,
fragment shading is massively parallel (frequently within tiles). It may be
that the execution order is not what you expect, or the access to shared
variables is also not what you expect. It's hard to tell from the code, since
the per-fragment linked-list approach you have is definitely ... novel."

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...

-- 
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/20190329/6b5eabc9/attachment-0001.html>


More information about the dri-devel mailing list