Fix crash in zero-copy games if dimensions are changed

[garbear]

Buffers can only be released on the rendering thread because they access graphics resources.

Motivation and Context

Reported here: kodi-game/game.libretro.pcsx-rearmed#13

How Has This Been Tested?

Tested on OSX with PCSX.

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

[garbear]

@MilhouseVH can you include this in your next build?

[MilhouseVH]

Will do.

[GTechAlpha]

FYI - This is required for zero-copy to work on pcsx-rearmed.

EDIT: Also, I do not think this PR is necessary. Only free buffers which are no longer valid are released, so there should be no conflict with rendering. If you leave them in, the pool is "contaminated" with invalid buffers.

EDIT2: Links.

[garbear]

"contaminated" buffers are dropped on the next flush, so these shouldn't be a problem sitting around for a bit

[GTechAlpha]

buffers are dropped on the next flush, so these shouldn't be a problem sitting around for a bit

Right. But we also miss out on the cool log message.

[garbear]

The problem is the free buffers are released on the game thread, which uses resources only available on the rendering.

Width and Height are passed on each frame, so instead of tearing everything down and reinitializing, what if we passed dimensions with the video data and stretched in real-time? Width and height would no longer be a state of the renderer, but of the buffer.

[GTechAlpha]

Are we talking about fixing this issue or a redesign? Because this issue (kodi-game/game.libretro.pcsx-rearmed#13) is resolved by this: libretro/pcsx_rearmed#178

[garbear]

I never observed the crash fixed by libretro/pcsx_rearmed#178, probably because I recompiled the core from master within the last week. This PR fixes a crash I observed when dimensions change.

[GTechAlpha]

This could be related: #14203

I have not experienced a crash since ^ + emu fix.

[garbear]

@GTechAlpha what about, for this PR, if we move free buffers of a different size to a "discard" vector that gets flushed on the rendering thread?

[GTechAlpha]

@garbear

Invalid buffers should really never be requested in the first place. When a dimension change occurs, a buffer should not be requested until the flush and reconfigure have completed. #14203 should ensure this.

So between #14203 and this PR (as it is now), there should be no need for a special discard vector, IMO.

I was wondering before how a free buffer being released under lock protection could cause a crash. I now see that free buffers are not always free.

[garbear]

Closing in favor of #14203