On 10/07/2020 13:08, Paul Gofman wrote:
Yes, sure, there should be some ways to introduce a workaround to make AION happy in the current buffer management logic, but probably a better solution is switching to persistent buffer mapping and overall buffer mapping logic redesign which AFAIK is being worked on and which I guess will obsolete such solutions. Also, the problem should probably not be present with the Vulkan backend.
I'm not sure how persistent buffer mapping does help with this, but let me add another piece of information:
The d3d9 vertex/index buffer memory management logic changed a lot between windows xp and vista+. It is also affected whether you have a single core or a multicore cpu (windows's d3d9 csmt equivalent seems to only activate if the app has access to at least 2 cores). I'm saying this to say that if the game relies on this behaviour, it is likely to be something the runtime does willingly since xp.
In the case of buffer locks, if you check the driver ddi you will notice efforts to be able to process locks without needing to block or flush the csmt thread.
In other words, the DISCARD can be processed before the internal gpu driver begins to process the calls needing the previous buffer data.
Thus if you observe a behaviour where DISCARD doesn't change the internal buffer, it is quite likely this behaviour is handled in the d3d9 runtime, not the internal gpu driver. If so, the logic behind this optimization must be quite simple, and probably doesn't check the buffer is busy or not.
In any case, I would suggest to check the behaviour on all vendors before going further.
Yours,
Axel Davy