dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it.
Date: Fri, 29 Mar 2019 14:31:09 +0000	[thread overview]
Message-ID: <bug-110229-502-w24hrYMHDe@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-110229-502@http.bugs.freedesktop.org/>


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

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

--- Comment #11 from Daniel Stone <daniel@fooishbar.org> ---
(In reply to Laurent from comment #10)
> -You load the first instruction (the boot) tho the GPU memory, it initialize
> the offset register to go to the next instruction but, there is no guarantee
> that the CPU has loaded the next instruction before the GPU is pointing to
> it.
> 
> The solution is to load the last instruction first, and the first
> instruction (the boot) last so, you're guarantee that all the shader
> instructions are loaded before the GPU start to execute them.

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.

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.

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.

I would try to begin by examining clearly what is going on at each step of your
fragment shader execution, so you can build a more precise theory of what is
going wrong. Good luck.

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

[-- Attachment #1.2: Type: text/html, Size: 2781 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

  parent reply	other threads:[~2019-03-29 14:31 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-23 22:55 [Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it bugzilla-daemon
2019-03-23 23:22 ` bugzilla-daemon
2019-03-24  8:34 ` bugzilla-daemon
2019-03-25 10:06 ` bugzilla-daemon
2019-03-25 10:06 ` bugzilla-daemon
2019-03-25 21:40 ` bugzilla-daemon
2019-03-26  0:27 ` bugzilla-daemon
2019-03-26 17:22 ` bugzilla-daemon
2019-03-26 22:09 ` bugzilla-daemon
2019-03-27  0:39 ` bugzilla-daemon
2019-03-27 17:33 ` bugzilla-daemon
2019-03-27 18:28 ` bugzilla-daemon
2019-03-29 14:23 ` bugzilla-daemon
2019-03-29 14:31 ` bugzilla-daemon [this message]
2019-03-29 15:43 ` bugzilla-daemon
2019-03-29 15:51 ` [Bug 110229] Textures binded to framebuffer objects or images are not correctly updated bugzilla-daemon
2019-03-29 21:36 ` bugzilla-daemon
2019-03-29 21:39 ` bugzilla-daemon
2019-03-30  8:11 ` bugzilla-daemon
2019-03-30 18:41 ` bugzilla-daemon
2019-03-31  3:08 ` bugzilla-daemon
2019-04-01  8:57 ` bugzilla-daemon
2019-04-01  9:11 ` bugzilla-daemon
2019-04-01 11:12 ` bugzilla-daemon
2019-04-01 11:19 ` bugzilla-daemon
2019-04-01 12:05 ` bugzilla-daemon
2019-04-01 12:20 ` bugzilla-daemon
2019-04-01 12:28 ` bugzilla-daemon
2019-04-08 13:19 ` bugzilla-daemon
2019-04-11 10:46 ` bugzilla-daemon
2019-04-11 10:47 ` [Bug 110229] glMemoryBarrier doesn't work bugzilla-daemon
2019-04-11 10:47 ` bugzilla-daemon
2019-04-11 11:31 ` bugzilla-daemon
2019-04-11 13:23 ` bugzilla-daemon
2019-04-11 13:28 ` bugzilla-daemon
2019-04-11 13:34 ` bugzilla-daemon
2019-04-11 15:00 ` bugzilla-daemon
2019-04-11 15:36 ` bugzilla-daemon
2019-04-11 15:39 ` bugzilla-daemon
2019-04-11 18:05 ` bugzilla-daemon
2019-04-12  9:53 ` bugzilla-daemon
2019-04-12 13:03 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-110229-502-w24hrYMHDe@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).