mirror/86box.github.io
1
0
Fork 0
mirror of https://github.com/86Box/86box.github.io.git synced 2026-02-21 17:15:35 -07:00
Code Issues Packages Projects Releases Wiki Activity

Initial review done

Browse Source
This commit is contained in:
RichardG867
2025-02-06 14:21:50 -03:00
parent 1bef1fe60e
commit 6b4180bd3a
1 changed files with 15 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
_posts/2025-01-22-riva128-part-1.md
View File

@@ -354,14 +354,25 @@ The `PFIFO_RUNOUT_STATUS` register holds the current state of the `RAMRO` region
I'm not really sure what `RAMAU` is for, but I assume it's a spare area for random stuff.
### Interrupts 2.0: Notifiers
However, some people at NVIDIA decided that they were too cool for interrupts. Why have an interrupt that tells the GPU to do something, when *you could have an interrupt that has the GPU tell the drivers to do something!*. So they implemented the incredible "notifier" system. It appears to have been implemented to allow the drivers to manage the GPU resources when the silicon could not implement them. Every single subsystem in the GPU has a notifier enable register alongside its interrupt enable register (some have multiple different notifier enable registers for different types of notifiers!) Notifiers appear to be intended to work with the object class system (although they may also exist within GPU subsystems, they mostly exist within `PGRAPH`, `PME` and `PVIDEO`) and are actually different *per-class of object* - with each object having a set of "notification parameters" that can be used to trigger a notification and are triggered by the `SetNotify` method at `0x104` within an object when it is stored inside of RAMHT. There is also the `SetNotifyCtxDma` method, usually but not always at `0x0`, which is used for the aforementioned context switching. Notifiers appear to be "requested" until the GPU processes them, and PGRAPH can take up to 16 software and 1 hardware notifier type.
More research is ongoing. It seems most notifiers are generated by the driver in order to manage hardware resources that they would not otherwise be capable of managing, such as the PFIFO caches.
Some people at NVIDIA decided that they were too cool for interrupts and thought: why have an interrupt that tells the GPU to do something, when you could have an interrupt that has the GPU tell the drivers to do something? And thus the incredible *notifier* system was born.
Notifiers appear to have been implemented to allow the drivers to manage GPU resources implemented in software instead of silicon. Every single subsystem in the GPU has a notifier enable register alongside its interrupt enable register, with some having multiple enable registers for different notifier types; notifiers are mostly found within `PGRAPH`, `PME` and `PVIDEO`, but may also exist in other subsystems.
`PGRAPH` notifiers appear to be intended to work with the object class system, and actually differ depending on the object class, with each object having a set of "notification parameters" that can be used to trigger the `SetNotify` method at `0x104` within an object stored in `RAMHT`. There is also the `SetNotifyCtxDma` method, usually but not always at `0x0`, which is used for context switching. Notifiers appear to be "requested" until the GPU processes them, and `PGRAPH` can take up to 16 software and 1 hardware notifier type.
More research is ongoing. It seems most notifiers are generated by the driver in order to manage hardware resources that they would not otherwise be capable of managing, such as the `PFIFO` caches.
### PRAMDAC
The final part of the GPU that handles the intricacies of generating a video signal, sets the resolution, and holds a color lookup table for the various modes. I haven't looked into this part as much, so expect more information in an update on this part or in future parts of this series. It's not really super critical to emulate anyway, other than the fact it actually controls the aforementioned clocks - but the actual video-generation part mostly does not apply to emulation as we don't need to generate an analog video signal.
The final part of the GPU that handles the intricacies of generating a video signal, sets the resolution, and holds a color lookup table for the various modes.
I haven't looked into this part as much, so expect more information in an update on this part or in future parts of this series. It's not really super critical to emulate anyway, outside of the [clock control portion](#clocks), as the actual analog video generation part mostly does not apply to emulation.
---
## Next Part
## Next part
The next part will dive into how NVIDIA's drivers work and how they make this ridiculously complicated mess of an architecture transform itself into a GPU that allows you to run games you may actually want to play. Stay tuned!
---