Storing textures in the VRAM as hash table

OpenGL Development
#1

Hello there!
One of the methods of storing the textures is by using hash tables. It’s very nice, because we can call the data by a string we can build easily on-fly. For example, I want to render a pine tree that have 20th (dec) texture. In order to render it I can build the string “tree_pine_20”, or “tree_07_20” because the id of tree is, for example, 07 (dec). It’s very comfortable, but the textures are kept in the RAM and the hash table is maintained by the CPU (if I’m not mistaken), and it’s not good, especially if I have render very much of them. It can kinda lower the FPS.
Now, I’d like create a hash table that will be maintained by the GPU rather by the CPU. It means that all functions of putting, getting, searching and erasing will be done in the GPU. Is it even possible?
Thank you very much!

#2

Hello

Maybe you’re looking for resident textures:
https://registry.khronos.org/OpenGL/extensions/ARB/ARB_bindless_texture.txt

You can store those 64-bit unsigned integers into the data structure of your choice.

#3

Ok. So, I’ve also reviewed the source code of Slick2D, and understood that the textures are stored in the VRAM.
Also, I’ve seen this:

The first problem is that I don’t need ints or longs, but strings as the key. The second one is that in the second link the source code uses CUDA, and it works only in NVIDIA, if I’m not mistaken

#4

You can trivially convert numbers to strings or use your own mapping between those numbers and your strings. What are you trying to achieve?

#5

You know, that seems good, but it will require mapping, limitations, etc. Also, it is less human-readable, but seems faster

Ok. So, now I have to render a fifth marble texture on a wall, for example. Marble index is 274 (dec). I call a subprogram renderTexture("terrain_274_04", other_args...). After that I should render a cow. For this I call another subprogram renderMob("mob_cow_f12", x, y, z, etc.), that also calls the "mob_cow_f12" model stored in the VRAM as well. The "mob_cow_f12" key is built from the next components:

  1. "mob" - indicates that the texture belongs to the mobs
  2. "cow" - indicates the mob type
  3. "f" - indicates the sex of the mob (female)
  4. "12" - indicates the shape of the mob (13th)
#6

You’ll have to determine at runtime whether you still need a texture in order to decide whether to go on storing it.

You won’t find any solution to store an hash table or Java strings in OpenGL and using OpenCL to do that is a bit overkill (and potentially inefficient) in my humble opinion even though it’s doable. Your scenegraph knows which resources are in use, it can use your strings as human-readable identifiers, it can store the mappings between your strings and the integer texture and image handles internally so that most of your source code can use your strings while the handles can be used internally to communicate with OpenGL, you have the best of both worlds. Imagine that you succeed in storing your strings into OpenCL somehow, you would still need to store them into Java too. Maybe using a texture atlas would be even more efficient in some cases.

The solution you mention has some serious limitations too, it doesn’t scale very well:
“Keys are not removed from the table by the delete function, and clutter the table over time”

I’m not sure that you really need an hash table stored into the GPU to solve your problem, especially because the heaviest part, the texture data, can reside in the GPU and you can use strings to identify your resources without using a GPU hash table anyway. You can get rid of the data passed to glTexImage2D (a direct NIO buffer or something more modern if you use Foreign-Memory Access API) just after creating your texture so that you don’t keep it on the CPU side and use my solution to be sure that it’s really only in the GPU.

#7

I think that the rendering should work in the next way: at the initializations the CPU sends to the GPU and to the VRAM the rendering sub-programs and the resources, like textures, fonts, important information etc. The most used strings also can be stored in the VRAM, preferably in UTF-16 or even UTF-32 format.
At the game CPU only sends the data to rendering, such as the world map, NPCs, GUI, text and so on. GPU renders all of it by the sub-programs and resources it has accepted from the CPU. The data should not be in the complex formats, arrays for the map, for example, are a good option.
When the game is finished, CPU sends to the GPU a command to free the VRAM