Fcalva/gint
1
0
Fork 0
mirror of https://git.planet-casio.com/Lephenixnoir/gint.git synced 2024-12-29 13:03:36 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

minor API comment update

Browse source
This commit is contained in:
Lephe 2022-09-07 23:25:43 +02:00
parent 3e5c45c5ad
commit e95a91d5ab
No known key found for this signature in database
GPG key ID: 1BBA026E13FC0495
2 changed files with 14 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
include/gint/display-cg.h
View file

@ -70,31 +70,27 @@ typedef image_t bopti_image_t;
// Video RAM management // Video RAM management
//--- //---
/* dsetvram() - Control video RAM address and triple buffering /* dsetvram(): Control video RAM address and triple buffering
Normal rendering under gint uses double-buffering: there is one image Normal rendering under gint uses double-buffering: there is one image
displayed on the screen and one in memory, in a region called the video RAM displayed on the screen and one in memory, in a region called the video RAM
(VRAM). The application draws frames in the VRAM then sends them to the (VRAM). The application draws frames in the VRAM then sends them to the
screen only when they are finished, using dupdate(). screen only when they are finished, using dupdate().
On fxcg50, the performance bottleneck is almost always the graphical On fx-CG, sending frames with dupdate() is a common bottleneck because it
rendering (especially in games) because the high amount of data, 173 kB per takes about 11 ms. Fortunately, while the DMA is sending the frame to the
frame in full-resolution, makes graphics manipulation computationally display, the CPU is available to do work in parallel. This function sets up
expensive. The transfer also takes about 10 ms in itself. triple buffering (ie. a second VRAM) so that the CPU can start working on
the next frame while the DMA is sending the current one.
Since gint transfers data to the screen using the DMA, it is possible to run However, experience shows minimal performance improvements, because writing
the application while the finished frame is being transferred. However, to main RAM does not parallelize with DMA transfers. Since gint 2.8, this
writing to the VRAM during this period will cause display artifacts since is no longer the default, and the memory for the extra VRAM is instead
the VRAM it is still being read by the DMA. available via malloc().
The solution to this is to use triple-buffering with the display and two VRAMs must be contiguous, 32-aligned, (2*396*224)-byte buffers with 32 bytes
VRAMs that are alternately being written to while the other is being of extra data on each side (ie. 32 bytes into a 32-aligned buffer of size
transferred. The VRAM switching is handled by dupdate() and is activated 177472).
whenever two VRAMs are configured.
By default gint uses triple buffering with two VRAMs in the system stack.
VRAMs must be contiguous, 32-aligned, (2*396*224)-byte buffers.
@main Main VRAM area, used alone if [secondary] is NULL @main Main VRAM area, used alone if [secondary] is NULL
@secondary Additional VRAM area, enables triple buffering if non-NULL */ @secondary Additional VRAM area, enables triple buffering if non-NULL */

2
src/dma/dma.c
View file

@ -178,7 +178,7 @@ static void dma_channel_wait(int channel, bool foreign)
if(!ch) return; if(!ch) return;
/* If interrupts are disabled or we don't own the device, spin-wait by /* If interrupts are disabled or we don't own the device, spin-wait by
checking either for TE to be set (Transfere Ended) or DE to be gone checking either for TE to be set (Transfer Ended) or DE to be gone
(channel disabled). (channel disabled).
There are definitely race conditions if the DMA is restarted between There are definitely race conditions if the DMA is restarted between