I have white-listed you, so you should be able to post directly in any of the AMD developer forums.
I am moving this post to the OpenGL forum, where you should receive useful responses.
I investigated this issue further and here is what I found:
1) Independent of the textures sizes problems start as soon as 465 textures are resident.
2) In my smaller repro case the problem is always the same: A call to glDrawElements does not return as soon as 465 textures are resident. My test:
a) Make one texture resident
b) Render that texture
c) Make another texture resident
d) Render the first(!) texture again
e) Jump to c)
After looping through c)-e) 455 times drawing the first texture does not return...
3) In my full application sometimes access violations occour as soon as 465 or more textures are resident, but in most cases drawing stalls.
4) It's the number of textures currently resident, not the overall number of glMakeTextureResident calls that causes the problem. Making 200 textures resident, rendering them and making them non resident again can be repeated thousands of times without issues.
5) Rendering works correctly as long as there are less textures resident. On nVidia hardware renderings works without problems for large numbers of resident textures. This makes me quite sure, that it's not a bug in my code.
Does anybody use large numbers of resident textures on AMD hardware? Any experiences?
Did anybody succesfully try to make more than ~465 resident using AMD OpenGL drivers?
1 of 1 people found this helpful
I created a minimal reproducer for this issue. A visual studio project is attached.
In the beginning of main.cpp the number of textures used can be set (count = x). If I choose the number smaller than 466 it runs without any issues. With larger number it hangs on AMD GPUs. For NVidia it works with 4096 and larger.
1) Can anyone confirm it on his machine?
2) Did I do anything wrong in my code?
Thanks for your help in advance,
Did anyone test my reproducer? In the meantime I know that there is at least one other software project experiencing the same problem. Unfortunately, there are no reactions from the AMD team until now. My bug report was ignored as well as this thread. How can I help to solve this issue?
For now my only workaround is to buy NVidia cards, which work without any issue...
I can reproduce this locally. Thanks for the test project by the way! I'll let you know once I have a fix.
It appears to be OS specific. I'm getting this issue with my 0 A.D. OpenGL 4 branch (GitHub - Yves-G/0ad at OGL4) and I've tested this branch and the minimised testcase on Ubuntu 14.04 and Windows 7 on my dual boot development machine (so the hardware is identical). My GL4 branch needs to be patched a bit to test this because it's crashing with some driver versions due to another driver bug (Crash introduced in driver 15.11 ). On my GL4 branch it sometimes hangs and sometimes crashes on the same test-map and player setup (Acropolis Bay - 2 Players, both Athenian to be precise) but it doesn't cause problems on all maps and all player setups, which is probably because smaller maps with less buildings and units use too few textures.
Some test results with different driver versions (Windows):
Driver version Testcase GL4 branch Non-WHQL-64Bit-Radeon-Software-Crimson-16.6.1-Win10-Win8.1-Win7-June2 Hangs Hangs/crashes amd-catalyst-15.7.1-with-dotnet45-win7-64bit Hangs Hangs/crashes radeon-crimson-15.12-with-dotnet45-win7-64bit Hangs Hangs/crashes
Test results on Linux:
Driver version Testcase GL4 branch Crimson Edition 15.12 (12/18/2015) OpenGL version string: 4.5.13416 Compatibility Profile Context 15.302 Works Works
I only discovered the problem when testing on Windows, so I'm quite sure that the problem does not occur with older drivers on Linux either (the one above is actually the newest driver for Linux). I've tested the 15.12 version on both systems, but I'm not sure if they actually contain the same versions of the relevant components or if it's just the downloaded bundle that gets the same version number.
Btw. I've modified the testcase a bit because I had difficulties to configure the right header include directories, lib search paths etc. on Linux. I've uploaded my version of it here:
1 of 1 people found this helpful
One of our engineers has solved the problem, and a fix should be released soon. I don't know the exact date that it will be available, but I will try to keep an eye on it and let you know. I would guess it will take a month or maybe two.