iMineLink
commented
6 years ago I'm totally positive with idea 3. Though it may be easier to keep track of an upper bound RAM/VRAM usage of the pool (putative), and replace the existing recycling logic which does not take that information into account, i.e.:
void GSDevice::Recycle(GSTexture* t)
{
if(t)
{
t->last_frame_used = m_frame;
m_pool.push_front(t);
//printf("%d\n",m_pool.size());
while(m_pool.size() > 300)
{
delete m_pool.back();
m_pool.pop_back();
}
}
}with something that prioritizes clearing bigger textures first from the pool, and then smaller only if needed (keeping a maximum number of total textures in the pool to avoid the logic slowing down operations):
void GSDevice::Recycle(GSTexture* t)
{
if(t)
{
t->last_frame_used = m_frame;
m_pool.push_front(t);
// MemUsage computes an upper bound memory consumption for the texture
m_mem_usage += MemUsage(t);
//printf("%d\n",m_pool.size());
double mem_cutoff = 0.25 * AVAILABLE_MEM;
while(m_mem_usage > 0.5 * AVAILABLE_MEM)
{
bool any_deleted = false;
for(auto i = m_pool.begin(); i != m_pool.end(); )
{
GSTexture* tt = *i;
if(MemUsage(tt) > mem_cutoff)
{
m_mem_usage -= MemUsage(tt);
delete tt;
i = m_pool.erase(i);
any_deleted = true;
if (m_mem_usage <= 0.5 * AVAILABLE_MEM)
{
break;
}
}
else
{
++i;
}
}
if (!any_deleted)
{
mem_cutoff /= 2;
}
}
}
}Though the nested loop is not nice, the GSFastList implementation should make iterating the pool really fast.
rcaridade145
jobs-git
lightningterror
FlatOutPS2
gregory38
mirh
refractionpcsx2
Please find some ideas to improve gsdx
On the SW renderer, final image is uploaded to the GPU. Current code rely on an external buffer which is copied in kernel space, then GPU thought the "Update". Instead we should use a map/unmap pattern. It will avoid a memcpy of the image as we directly write data to kernel space. (note it might hurt perf is the kernel space is actually already a distant gpu memory)
Rendering threads are connected to main thread with ring buffers. Currently we send scanline one by one in the ring buffer. Maybe it would be more efficient to pack them in small array and send the array (of scanline) in the ring buffer.
GSdevice contains a pool of unused texture to avoid slow reallocation. Currently the pool contains input texture/color buffer / depth buffer. Input textures are rather small however color/depth buffer can be huge due to upscaling. The idea is to split the pool by GStexture type. So we can have a big pool for small texture and another small pool for large color/depth buffer. It will typically help to reduce GSdx memory spikes.
Palettes are attached to a data texture, what I mean is that you always have 2 textures (a texture that contains data, a texture that contains the palette). It doesn't work great when game uses multiple palettes for the same data texture (we re-upload the palette texture => ZoE). An idea would be to decorrelate the palette from the data texture. One we could imagine a hash-table that contains all palettes. So we can upload the data once and future access will only be a rebind of the palette. It would be nice to have a fast-path that avoid the hash lookup as most of the time the data texture will use the same palette.
Palettes are handled with 2D texture (size 256x1). It would be better to replace it with a big texture buffer (potentially big enough to contains all game palettes, a palette is 1KB of data). Texture buffer is a linear piece of memory which mean that we can write data from the CPU directly without DMA (real zero copy). We need to ensure that buffer is allocated on VRAM (not RAM) to ensure fast texel fetch from the shader. However it means that we need to implement manually the synchronization (especially if we update the data, if buffer is big enough sync will be useless).
During the rendering, a game could reuse an old target (frame buffer) as an input texture. The target is often downscaled/rescaled to ensure correct texture coordinates which are relatives to the size of the texture. Rescaling is slow and reduce quality. We should try to avoid it. The proposal is to track the size of valid texel in the target (could be based on the FBW and end page block) to copy only the useful data. For example, let's say GS input texture is 1024x1024. Rendered data in the target is 640x480 with an upscale factor of 2. We could create an input texture of 2048x2048 with the help of sparse texture and copy only the 1280x960 texels.