3 ms·

The debugging of "5.0-10379 - VideoCommon: Constrain the array_base registers by booto" is just insane. Props to the person ("booto") who managed to go through

by sweden 7y ago

The debugging of "5.0-10379 - VideoCommon: Constrain the array_base registers by booto" is just insane. Props to the person ("booto") who managed to go through this, you are an example for any of us.

FartyMcFarter 7y ago
It's a nice debugging story, but I actually thought it was a bit anti-climactic. I say that because hardware that ignores irrelevant address bits is not really a rare or surprising thing. The more primitive/simple the hardware the more this is likely to happen. After all, "why bother" checking those bits or piping them through to a memory bus if they couldn't possibly affect the result? It was however a nice description of the process by which the bug was reproduced and analyzed! Also, props to whoever managed to isolate that repro case. PS: If you're into crazy game bugs, here's another one: https://twitter.com/mmalex/status/1066111290580582403 https://twitter.com/mmalex/status/1066111290580582403
- tntn 7y ago
  Right, the behavior for "out of bounds" addressing is frequently (ab)used. Tagged pointers have been used in loads of stuff. I think x86_64 prohibits this and the MMU will fault if there are interesting things in the high bits, but it still works on aarch64 systems.
  - dtech 7y ago
    x86_64 disallows this because the 286 only used the lower 24 bits of a memory address, which made developer (ab)use the extra bits like you said. This causes all kinds of havok with some 486 variants and the Pentium, which did use the full 32 bits. AMD's original x86_64 CPU (Opteron) only used the lower 48 bits of the address (I think modern cpus still do), so to prevent any future problems they disallowed using the upper 16 bits.
    - BubRoss 7y ago
      Most CPUs have used 42 bits for quite a while and only recently has Intel been making 48 bit addressing CPUs.

3 ms·

The debugging of "5.0-10379 - VideoCommon: Constrain the array_base registers by booto" is just insane. Props to the person ("booto") who managed to go through

by sweden 7y ago

The debugging of "5.0-10379 - VideoCommon: Constrain the array_base registers by booto" is just insane. Props to the person ("booto") who managed to go through this, you are an example for any of us.

FartyMcFarter 7y ago
It's a nice debugging story, but I actually thought it was a bit anti-climactic. I say that because hardware that ignores irrelevant address bits is not really a rare or surprising thing. The more primitive/simple the hardware the more this is likely to happen. After all, "why bother" checking those bits or piping them through to a memory bus if they couldn't possibly affect the result? It was however a nice description of the process by which the bug was reproduced and analyzed! Also, props to whoever managed to isolate that repro case. PS: If you're into crazy game bugs, here's another one: https://twitter.com/mmalex/status/1066111290580582403 https://twitter.com/mmalex/status/1066111290580582403
- tntn 7y ago
  Right, the behavior for "out of bounds" addressing is frequently (ab)used. Tagged pointers have been used in loads of stuff. I think x86_64 prohibits this and the MMU will fault if there are interesting things in the high bits, but it still works on aarch64 systems.
  - dtech 7y ago
    x86_64 disallows this because the 286 only used the lower 24 bits of a memory address, which made developer (ab)use the extra bits like you said. This causes all kinds of havok with some 486 variants and the Pentium, which did use the full 32 bits. AMD's original x86_64 CPU (Opteron) only used the lower 48 bits of the address (I think modern cpus still do), so to prevent any future problems they disallowed using the upper 16 bits.
    - BubRoss 7y ago
      Most CPUs have used 42 bits for quite a while and only recently has Intel been making 48 bit addressing CPUs.