GT9524 (1.18@6307965): subpassLoad ignores rasterization order attachment access

PowerVR Insider
1

TOPST D3-G (Telechips TCC8050, Linux, GT9524, driver 1.18@6307965) advertises VK_EXT_rasterization_order_attachment_access and reports
rasterizationOrderColorAttachmentAccess = VK_TRUE, but it doesn’t actually work.

Test:

  • One RGBA8 attachment used as both color and input in the same subpass. GENERAL layout, loadOp = CLEAR
  • Feature enabled, ROAA flags set on the subpass and the pipeline
  • First draw fills (0, 128, 0, 255)
  • Each following draw adds 1 to red on the subpassLoad value
  • No barriers between draws

After one draw I expect (1, 128, 0, 255) but get (1, 0, 0, 0). Same with 8 draws. Every draw reads the value from render pass begin, not the previous draw’s
output.

  • ROAA, no barrier: 100% wrong
  • ROAA + barrier: correct
  • No ROAA + barrier: correct

Dropping the ROAA flags, adding a self-dependency or using loadOp = LOAD doesn’t change anything.

Found this in PCSX2 (ARMSX2). If we trust ROAA and skip the barrier, we get black tiles all over the screen. So we keep a barrier per blended draw, at 25 to 35 µs
each, and it’s slow.

  1. Is this a known issue? Is it fixed in a newer DDK?
  2. If so, which version should I ask Telechips for?

Repro: PowerVR GT9524: subpassLoad ignores rasterization order attachment access (repro) · GitHub

2

Interesting report. Since ROAA without barriers fails while the explicit-barrier path works, this looks like a possible issue with the implicit framebuffer-local dependency provided by the extension.

According to the Vulkan specification, ROAA should provide the required ordering between color attachment writes and subsequent input attachment reads at the same framebuffer location, including across draw calls.

One additional experiment might help narrow this down:

Could you try putting the overlapping fragments into a single draw call, rather than separate draws, while keeping ROAA enabled and removing the explicit barriers?

If that works, but the multi-draw version still fails, it could help distinguish a cross-draw synchronization issue from a more general ROAA implementation problem.

If both fail, I can’t figure that out, it has to be done with imagination

I can’t confirm whether a newer DDK fixes this, but your reproducer looks like a useful starting point for investigating it.

3

Thanks, good idea. Tried it.

Added a mode where one draw has several overlapping fullscreen quads, so every quad should see the one before it. It fails too. Here’s the same test drawn in a Wayland window (labels are the centre pixels read back from that run):

Screenshot from 2026-10-13 22-09-34
Screenshot from 2026-10-13 22-09-342336×574 27.5 KB

  1. fill > barrier > add: OK
  2. fill > add, ROAA only: green lost, reads the value from render pass begin
  3. fill > 4x (barrier > add): OK, R160 is what 4 layers should look like
  4. fill > add x4 overlapping, ROAA only: green lost
  5. fill > barrier > add x4 overlapping: green is there but red stops at 40, so the 4 quads in one draw don’t see each other

So it fails both ways. Within one draw and across draws, only an explicit barrier gets the previous write into subpassLoad. Looks like ROAA just isn’t implemented, not a cross-draw sync problem.

Gist is updated with both the offscreen test and the Wayland version (roaa-wl).

4

Thanks for running the additional tests! These results are really useful.

Test 5 is particularly interesting: the explicit barrier makes the initial green value visible, but the four overlapping quads still fail to accumulate their red contributions.

Since ROAA fails both across separate draw calls and within a single draw, this doesn’t appear to be just a cross-draw synchronization issue.

Assuming the reproducer is valid and the extension is configured correctly, this looks like a possible driver conformance issue.

Could you also check whether the Vulkan validation layers report any errors?

I’ll send an email to Imagination Technologies about this, including your findings and the reproducer, to see whether they’re aware of the issue and whether a newer DDK addresses it.

In the meantime, keeping the explicit barriers seems like the safest workaround for ARMSX2.

Thanks again for investigating this!

5

Ran it with the Khronos validation layer (1.3.204, the Ubuntu 22.04 package). It found one thing on my side: the barrier cases had no subpass self-dependency. Fixed that, and now every case is clean. Results didn’t change. The ROAA-only cases had no errors from the start.

That layer is older than the EXT name but knows VK_ARM_rasterization_order_attachment_access, so I also ran everything with the ARM name (FT_ARM_EXT=1) to make sure the ROAA checks apply. Same results, no errors.

Gist is updated. Thanks for passing it on to IMG!

1 Like
6

No problem! For some reason, NO ONE from Imagination (except Simon) is replying to anything on this forum. I sent them an email (no response so far); it’s strange, to say the least.

They probably see the forum but don’t reply; the forum only has 4 moderators

7

Hello @Operating ,

I’m here as well :smiley:. Apologies for the delay, let’s see what we can do.

Thank you very much for the detailed repro case saenggeuri, it’s pretty complete.

1.18@6307965 it’s a bit old. I believe VK_EXT_rasterization_order_attachment_access works properly on the latest version of the drivers.

Let me talk with the driver team, to see if we can provide a workaround for 1.18@6307965.

Thank you again for your patience.