GSP service "gsp::Gpu"
|Command Header||Available since system version||GSP rights required||Description|
The GSP module starts a thread for handling commands for each service session, a maximum of 4 processes can use this service at once. Official applications have an optional code-path which writes to registers during initialization, this is normally not used however.
GSP service "gsp::Lcd"
|Command Header||Available since system version||Description|
|0x00140000||8.0.0-18||GetVendor New3DS-only, stubbed on Old3DS: This only returns an error. Uninitialized data(not set by this command itself) is also written to u8 cmdreply_word.|
|0x00150040||8.0.0-18||GetBrightness New3DS-only, stubbed on Old3DS: This only returns an error. Uninitialized data(not set by this command itself) is also written to u32 cmdreply_word.|
Unlike gsp::Gpu, GSP module does not start a separate thread for handling these service commands.
|v8196||Support for the new LINEAR memory region was implemented(for cache commands and vaddr->physaddr conversion). Support for the new process-mem 0x1E800000 region(however the GPU can't actually access this memory) was added for vaddr->physaddr conversion. Originally GSP module ignored vaddr->physaddr conversion errors(like with vaddrs outside of the handled ranges) and just wrote physaddr value0 to the GPU registers, however now GSP module returns an error for that instead(see here regarding errors being written to GSP shared-mem). New services commands were added too, see above.|
There's separate GSP-module titles for Old3DS and New3DS. PTM CheckNew3DS is only used by the New3DS title, for copying that flag into a state field. Elsewhere that field is checked for running additional code only on New3DS, for processing various state / using QTM commands.