I am using the GL_ARB_bindless_texture extension and am experiencing crashes due to access violations when using it together with AMD drivers (15.7.1 as well as 15.11.1 Beta, did not test with older drivers).
The software works fine when used together with NVidia drivers. Also it works correctly when I do not make more than ~460 textures resident (glMakeTextureResidentARB) at a time. The textures together do not use > 40MB memory, so this can't be the problem. Allocating more than >1GB of textures works without problems in non-bindless mode and also in bindless mode as long as I do not make them resident.
Does anybody experience similliar problems? Is there a limit how many textures can be resident at a time? Any ideas?
Thanks in advance,
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?
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...
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|
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:
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.