Showing changes from revision #3 to #4:
Added | Removed | Changed
Entry | |
---|---|
R0 | Flags: |
Bit 0: Synchronise | |
Bit 1: Synchronise if unclaimed | |
R1 | Render operation: |
0 = No-op | |
1 = Copy rectangle | |
2 = Fill rectangle | |
R2 | Pointer to operation parameter block |
R4 | Bits 0-23: 13 (reason code) |
Bits 24-31: Display number |
Exit | |
---|---|
R4 | 0 |
- | All other registers preserved |
The kernel issues this call to instruct the driver to perform a hardware-accelerated rendering task. The appropriate driver should respond to the call in the following manner:
The default claimant of this call is the kernel. If the call is left unclaimed, and the call was for display 0, the kernel will try calling HAL_VideoRender. If this call succeeds then the kernel will claim the call by setting R4 to 0.
If no driver responds to the request then there is no generic software fallback in place. Software rendering fallbacks must be handled on a case-by-case basis by the caller. Therefore any user software which wishes to make use of hardware acceleration should either do so via the VDU interface (e.g. use block copy/fill OS_Plot operations, which will have the appropriate fallbacks in place inside the kernel), or call GraphicsV directly and use their own software fallback for any unsupported operations. Just because one call succeeds it does not guarantee that the next call will succeed, or that a call made with slightly different parameters will succeed.