The problem of #1717 is already fixed and the user just opened an identical issue to ask for a build.

#1721 seems to be just a stupid game that spams API calls (not even draw calls) like there's no tomorrow.

@Joshua-Ashton can you take a look at some point?

@mirh please don't hijack other people's issues. If you have anything specific to report and can provide us something to work with, please open a separate issue.

Is this still an issue?

Your game is Master Arena, right?
https://store.steampowered.com/app/704020/Master_Arena/

@jeremweb I finally took a look at the game and I gotta say: what the actual fuck is that light shaft implementation.

To create this:

You could just render a single triangle with a gradient and blending (or maybe some more triangles). The light shafts in the game don't do something fancy like casting shadows (something that other games do).

Instead the game somehow renders a line:

And then runs a fullscreen pass to render the light shaft.
That fullscreen pass runs a loop with 32 iterations and each iteration does 2 texture samples.
The texture it sample from is also a R16G16B16A16_UNORM texture to make sure it wastes as much bandwidth as possible.
This is also needlessly executed for the entire screen, even though 80% of pixels are completely black.
No viewport, stencil, discard or anything like that used.

defi i0, 32, 0, 0, 0
rep i0
      mov r4.zw, r4.xyxw
      mul r5.xy, r4.zwzw, r4.zwzw
      mul r5.zw, r5.xyxy, c2.w
      mad r5.xy, r5, c2.w, -r4.zwzw
      cmp r4.xy, r5, r4.zwzw, r5.zwzw
      max r5, r3, c8.xyxy
      min r6, c8.zwzw, r5
      texld r5, r6, s0
      mad r5, r5, r4.xxxz, r2
      texld r6, r6.zwzw, s0
      mad r2, r6, r4.yyyw, r5
      add r4.xw, r4.zyzw, c3.x
      mad r3, r1, c2.y, r3
    endrep

On top of that the renderer copies that texture from one texture to another dozens of times both before and after those light shafts are generated.

There's 4 different textures like that:

Some even do frequent clears in between to make it waste even more bandwidth on desktop GPUs.

It's not exactly clear why any of this is done. Most of the fullscreen draws in that list before EID 10025 (the one that generates the light shafts) are completely black.

I think each volumetric light does 4 of those fullscreen passes and one of the fullscreen passes for each light is the one with that 32 iteration loop. I counted at least 5 lights and I didnt go over all draws. (the mars map)

You really should do some culling instead of processing every single light like that even when they don't contribute to the final image at all because they aren't on screen.

To be perfectly honest, all of this is terrible and I have no idea how this isn't super slow on the Nvidia D3D9 driver.
I don't see anything we're doing wrong here or any opportunity to optimize this.
As far as I can tell, it's not possible to move the texture samples outside of the loop because each iteration impacts the texture coords used for the next one.

It's possible that the Nvidia compiler struggles to optimize our specialization constant based texture sampling when it's in a loop like that.

BTW I also really don't see why the game needs 6200 different shaders.