New subject: [Bug 58622] A shader with large loops is very slow to compile

Aug. 21, 2025

      http://bugs.winehq.org/show_bug.cgi?id=58622

            Bug ID: 58622
           Summary: A shader with large loops is very slow to compile
           Product: vkd3d
           Version: 1.17
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Keywords: download, source, testcase
          Severity: normal
          Priority: P2
         Component: hlsl
          Assignee: wine-bugs(a)winehq.org
          Reporter: z.figura12(a)gmail.com
      Distribution: ---

Created attachment 79172
  --> http://bugs.winehq.org/attachment.cgi?id=79172
shader

Attached shader is from a real application, meant to be compiled with ps_5_1.

Disabling loop unrolling helps. That doesn't mean that we need to target loop
unrolling specifically, though. There may be other things we can improve.
Here's what's been observed so far:

* copy-prop is doing a *lot* of work; it's an important part of loop unrolling.
Copy-prop is doing a lot of work partly because we're generating an awful lot
of synthetic variables for various reasons, not all of which are necessary:

  - <index-val> variables can be avoided in 99% of cases. I've slapped together
a heuristic that checks if we're indexing a LOAD and if there's nothing
potentially problematic between the LOAD and INDEX, and it gets rid of all the
<index-val> cases.

  - <deref> variables exist for the same reason IIRC and can probably be
avoided with the same heuristic.

  - Temp copies for the uniforms [and there's some very big uniform arrays in
this shader, which are also largely responsible for the many index-vals.] The
uniforms aren't written, but we still generate the copies in case they are. DCE
before anything else might help, but even better would be avoiding generating
them in the first place.

    * We can do this trivially because the uniforms are implicitly const,
although this is something we'll need to fix with new API. However it may
generally be possible to do this without having to rely on that knowledge. I
suspect there are a decent number of large shaders in the wild that use
backcompat flags or old compilers but whose uniforms are still constant. Well,
maybe. Maybe we should just implement implicit const first.

  - That first fromTangentToWorld assignment, and I think several other
assignments, are resulting in a cast for some reason, which is generating a
bunch of <cast> synthetics when splitting. That shouldn't... cast? Why is that
casting?

* Native seems to struggle with unrolling this shader quickly as well.

* Native is known to limit loop unrolling by execution time at least under some
circumstances. If we have to do that here, so be it.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 58622] New: A shader with large loops is very slow to compile

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)