Skip to content

ppcmmu: Ignore dcbz for MMIO regions - #203

Merged
dingusdev merged 1 commit into
dingusdev:masterfrom
mihaip:upstream-dcbz-mmio
Aug 8, 2026
Merged

ppcmmu: Ignore dcbz for MMIO regions#203
dingusdev merged 1 commit into
dingusdev:masterfrom
mihaip:upstream-dcbz-mmio

Conversation

@mihaip

@mihaip mihaip commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

The ATI drivers uses dcbz to simulate a write-combining buffer when sending HOST_DATA payloads.

The intent is something like this (on real hardware):

dcbz:
    cache line = [0, 0, 0, 0, 0, 0, 0, 0]
    ATI sees nothing

following stores:
    cache line = [A, B, C, D, E, F, G, H]
    ATI still sees nothing

dcbf or eviction:
    write back [A, B, C, D, E, F, G, H]
    ATI receives one completed cache line

With our cacheless implementation, the behavior was more like this:

dcbz:
    ATI immediately receives [0, 0, 0, 0, 0, 0, 0, 0]

following stores:
    ATI then receives [A, B, C, D, E, F, G, H]

dcbf:
    no-op

The zero-ed out values have side effects (32 pixels of black being written), so the intermediate state was visible as visual corruption, especially visible when windows get redrawn on Mac OS 8.6.

The truly correct fix is to fully model the data cache, and do an eventual write back of the modified cache lines with their final values, but that is very invasive (and likely to be slow).

We instead just make dcbz a no-op for MMIO regions, which lets us avoid that intermediate state and unintended side effects.

The ATI drivers uses dcbz to simulate a write-combining buffer when
sending HOST_DATA payloads.

The intent is something like this (on real hardware):

```
dcbz:
    cache line = [0, 0, 0, 0, 0, 0, 0, 0]
    ATI sees nothing

following stores:
    cache line = [A, B, C, D, E, F, G, H]
    ATI still sees nothing

dcbf or eviction:
    write back [A, B, C, D, E, F, G, H]
    ATI receives one completed cache line
```

With our previous cacheless implementation, the behavior was more like this:
```
dcbz:
    ATI immediately receives [0, 0, 0, 0, 0, 0, 0, 0]

following stores:
    ATI then receives [A, B, C, D, E, F, G, H]

dcbf:
    no-op
```

The zero-ed out values have side effects (32 pixels of black being
written), so the intermediate state was visible.

The truly correct fix is to fully model the data cache, and do an
eventual write back of the modified cache lines with their final values,
but that is very invasive (and likely to be slow).

We instead just make `dcbz` a no-op for MMIO regions, which lets us
avoid that intermediate state and unintended side effects.
@dingusdev
dingusdev merged commit 8f6274e into dingusdev:master Aug 8, 2026
7 checks passed
@mihaip
mihaip deleted the upstream-dcbz-mmio branch August 8, 2026 18:47
dingusdev pushed a commit that referenced this pull request Aug 15, 2026
Helps a bit with some of the code duplication introduced in #203.
mihaip added a commit to mihaip/dingusppc that referenced this pull request Aug 21, 2026
PAT generation counters make invalidation constant-time by adding a
generation check to every TLB lookup, but they added a per-access overhead
to compare generation counters. I am swithcing to an alternate approach
(explicitly tracking populated entries, which can also be used for
BAT-derived entries), and am removing this first to make that diff
easier to read.

This logically reverts the work from dingusdev#199 (the TLB helper refactoring
from dingusdev#203 prevents a mechanical revert).
dingusdev pushed a commit that referenced this pull request Aug 21, 2026
PAT generation counters make invalidation constant-time by adding a
generation check to every TLB lookup, but they added a per-access overhead
to compare generation counters. I am swithcing to an alternate approach
(explicitly tracking populated entries, which can also be used for
BAT-derived entries), and am removing this first to make that diff
easier to read.

This logically reverts the work from #199 (the TLB helper refactoring
from #203 prevents a mechanical revert).
Link4Electronics pushed a commit to Link4Electronics/dingusppc that referenced this pull request Aug 21, 2026
PAT generation counters make invalidation constant-time by adding a
generation check to every TLB lookup, but they added a per-access overhead
to compare generation counters. I am swithcing to an alternate approach
(explicitly tracking populated entries, which can also be used for
BAT-derived entries), and am removing this first to make that diff
easier to read.

This logically reverts the work from dingusdev#199 (the TLB helper refactoring
from dingusdev#203 prevents a mechanical revert).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants