Qopenglbuffer - 64 bit addressing?

[NightShadeI]

Hi guys recently I stumbled on some bug where is was trying to reserve more than 2^31 bytes of buffer space with QOpenGlBuffer, but the API limits to using an int , which means we are restricted to what we can reserve. This is only around 2GB of space, I imagine modern GPUs can handle much more than this

Is there some way around this? Im trying to render a large grid , and with this restriction and my design, I can approximately only reach 3500 by 3500 which isn't very big.

I understand there are workarounds (breaking into chunks for example), but I'm more interested in if there is any way around this restriction or why it is imposed

Thanks!

[NightShadeI]

@NightShadeI

Any thoughts on this one? Would I have to use native GL buffers instead of the convenience wrappers? Can support be added?

[Christian Ehrlicher]

@NightShadeI said in Qopenglbuffer - 64 bit addressing?:

Can support be added?

As this would be an api change - no not until Qt7.

[Chris Kawa]

Although OpenGL API uses GLsizeiptr for the size, which is a 64 bit value, the actual allowed maximum buffer size you can access in a shader is limited to the value of GL_MAX_SHADER_STORAGE_BLOCK_SIZE. As you can see here this value is usually 2^31 or less on pretty much all modern consumer hardware. So although Qt limits what the spec allows, extending it wouldn't let you access more anyway.

If you need bigger buffers there are probably vendor specific extensions for that.

Out of curiosity - why do you need such a large buffer? A 4K display has 8 294 400 pixels, which at 32bit pixel format needs around 30MB of storage. You physically can't show more than that on screen at any given time, so I can't imagine why you would need over 2GB for any data. Also accessing it from a shader would be terribly inefficient due to it being so sparse and thus missing cache all the time.

I think a better course for you would be to rethink your architecture and structure your shader inputs differently.

[SGaist]

Hi,

I don't know the design decisions but this is coherent with the rest of the Qt API. Also, at the time of the writing of these classes, GPU memory was not that big and in the absolute they are still not compared to CPU memory. Also if you want such powerful cards, your budget is going to be pretty high.

These considerations aside, can you explain why you need such a big block of memory ? It seems a bit extreme.

[NightShadeI]

@SGaist @Chris-Kawa You're both probably right, the answer I guess was "convenience"

Im trying to make some game clone of a 2D grid game, and the original old game supported up to 200x200 ish tiles , there has always been requests for higher dimensionality so I wanted to see just how far I could push it. Was able to get to around 3200x3200 and still get some insane FPS

I was thinking also that as my VertexData size increases during further development that 3500x3500 limit will also decrease, but I think like Chris mentioned, maybe the solution is just to have a better approach (i.e. more buffers depending whats on the screen?)

The interesting thing about the original game is it allowed very close zoom in / zoom out , so I could probably also have different buffers dependant on the zoom kind of like mip-mapping, but honestly was just toying to see how high I could go before I ran into real issues!

edit: Another solution to probably push that higher might be indexed buffer rendering? I'm just doing a very basic 6 points per tile right now

I suppose we can mark as solved :) would be nice to try higher given my GPU definitely supports more than 2GB , but i'm satisfied with the answers here (and so many of them!)

[SGaist]

AFAIK, most if not all games adapt the level of details based on the zoom factor because there's no sense in calculating all the details of the grass at the limit of the forest located 2km away from you. But it start making sense when you are close to it.