Skip to content

Commit 4d4c0f9

Browse files
committed
Final round of riva128 corrections
1 parent 5b5f139 commit 4d4c0f9

File tree

1 file changed

+11
-16
lines changed

1 file changed

+11
-16
lines changed

_posts/2025-02-25-riva128-part-1.md

Lines changed: 11 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -148,7 +148,7 @@ There are several hundred different registers across the entire graphics card, s
148148

149149
### Fundamental concept: the scene graph
150150

151-
In order to begin to understand the NVIDIA NV3 architecture, you have to understand the fundamental concept of a scene graph. Although the architecture does not strictly implement a scene graph, knowing the concept helps understand how graphical objects are represented by the GPU. A scene graph is a description of a form of tree where the nodes of the tree are graphical objects, and the properties of a parent object cascade down to its children.
151+
In order to begin this journey through the NVIDIA NV3 architecture, you must understand the fundamental concept of a scene graph. Although the architecture does not strictly implement a scene graph, knowing the concept helps understand how graphical objects are represented by the GPU. A scene graph is a description of a form of tree where the nodes of the tree are graphical objects, and the properties of a parent object cascade down to its children.
152152

153153
This is how almost all modern game engines (Unity, Unreal, Godot...) represent 3D space. A very easy way to understand how a scene graph works is - I am not joking - install Roblox Studio, place some objects into the scene, save it as an `RBXLX` file (not the default), and open it in a text editor of your choice. You will see an XML representation of the scene you have created as a scene graph; the only caveat is that on Roblox, the cascading of characteristics from parent nodes to children is optional.
154154

@@ -361,25 +361,20 @@ Some people at NVIDIA decided that they were too cool for interrupts and thought
361361

362362
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.
363363

364-
`PGRAPH` notifiers appear to be intended to work with the object class system, and actually differ - there is basically one "type" of notification 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. Objects are signalled to the driver by directly DMAing into the Resource Manager memory; the notification is represented by an `NvNotification` structure. This structure takes the form:
364+
`PGRAPH` notifiers appear to be intended to work with the object class system, and actually differ - there is basically one "type" of notification 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. Objects are signalled to the driver by directly DMAing into the Resource Manager memory. Notifications are represented by a structure as such:
365365

366-
```
367-
typedef struct
368-
{
369-
struct
370-
{
371-
uint32_t nanoseconds[2];
372-
} TimeStamp;
373-
374-
int32_t info32;
375-
int16_t info16;
376-
int16_t status;
366+
```c
367+
typedef struct {
368+
struct {
369+
uint32_t nanoseconds[2];
370+
} TimeStamp;
371+
int32_t info32;
372+
int16_t info16;
373+
int16_t status; /* 0xFF (NV_NOTIFICATION_IN_PROGRESS) = pending; 0x00 = complete; others = error */
377374
} NvNotification;
378375
```
379376

380-
where the status is `NV_NOTIFICATION_IN_PROGRESS` (`0xFF`) when the notification is pending and `0x00` when it is complete. Any other value indicates an error.
381-
382-
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.
377+
More research is ongoing. It appears that 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.
383378

384379
### PRAMDAC
385380

0 commit comments

Comments
 (0)