GSP Shared Memory: Difference between revisions
m lil redesign |
Add bugs section |
||
Line 116: | Line 116: | ||
|- | |- | ||
| 2 | | 2 | ||
| Status ( | | Status (0x1 = halted, 0x80 = error) | ||
|- | |- | ||
| 3 | | 3 | ||
Line 126: | Line 126: | ||
After adding a command, [[GSPGPU:TriggerCmdReqQueue|TriggerCmdReqQueue]] must be used to start command processing (official code does so when the total commands field is 1). | After adding a command, [[GSPGPU:TriggerCmdReqQueue|TriggerCmdReqQueue]] must be used to start command processing (official code does so when the total commands field is 1). | ||
== Commands == | == Commands == | ||
Line 361: | Line 359: | ||
Any process must have acquired rendering rights, otherwise the error 0xD8202A06 (GSP_NO_RIGHT) is returned. | Any process must have acquired rendering rights, otherwise the error 0xD8202A06 (GSP_NO_RIGHT) is returned. | ||
== Bugs == | |||
* When issuing a DMA request, GSP attempts to acquire an internal semaphore that rules CDMA access; this semaphore is never released on failure paths. While this is generally not an issue, as GSP breaks on DMA failures, it becomes a problem if the DMA request is done with cache flushing: in that case, GSP will error silently, causing a deadlock in DMA code. | |||
* When handling GX commands apart from RequestDMA and ProcessCommandList, GSP sets the relative busy flags in internal state before executing the commands. This means that, if the relevant interrupts are never triggered (eg. on invalid parameters), the busy flags never get reset, preventing execution of future commands of the same kind. |