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

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 1968 bytes --]

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

--- Comment #14 from Laurent <laurentduroisin@gmail.com> ---
(In reply to Laurent from comment #13)
> "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...

And (I've forgot), using mutex is slow so, normally we don't use them with the
GPU.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2997 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel