Array limits for vertices, colors & co

[rainergericke]

Reworking our 3d code for vsg v1.0.8 I recognized the array limits are limited to uint32_t. Is there a technical reason for it?

[timoore]

The relevant limits on buffer sizes are limited to uint_32 in Vulkan. If you want to "map" data from larger storage areas into vertex attributes, then you could play games with the _data member.

…

On Wed, Aug 2, 2023, 8:58 AM Rainer Gericke ***@***.***> wrote: Reworking our 3d code for vsg v1.0.8 I recognized the array limits are limited to uint32_t. Is there a technical reason for it? — Reply to this email directly, view it on GitHub <#894>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAQAIASY56UO74WJJZIVDXTH3CVANCNFSM6AAAAAA3AZTHWQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[robertosfield]

As Tim says the structures that we map data to on the Vulkan size using uint32_t so the vsg::Data class mirrors this. THe limits didn't change in v1.0.8, ivsg::Data and subclasses have always had these limits, the changes were just cosmetic w.r.t type.

[rainergericke]

I see. Our old code worked with bigger arrays too, but it is broken now. For a general solution in our software it seems to be better, to avoid to big arrays.

Thanks

[robertosfield]

I am confused as how things work before but not now. The commit in v1.0.8 related vsg::Data/Array was a change from std::size_t to size_t for consistency purposes: b3c2939

What OS and compilers are you using? Is std::size_t and size_t different sizes?

[robertosfield]

Could you provide details of the compile errors you are seeing?

[rainergericke]

A small test program shows:
Size_t is 8 Byte
std::Size_t is 8 Byte

I am using MacOS 13.5 and the clang++ compiler include with Xcode.

When I try to build our code with vsg v1.0.8 I get these errors:

for these code lines

To see how the code worked look at the code excerpt:
code_excerpt.txt

[robertosfield]

These errors aren't to do with data size, but simply a refactor of vsg::ShaderSet/GraphicsPipelineConfigurator to be more flexible/extensible and to support multiple DescriptorSets. I couldn't avoid breaking backwards compatibility when making these improvements to these classes.

Have a look at the changes between v1.0.7 and v1.0.8 to VSG and the recent changes to vsgXchange and vsgExamples as they should illustrate the changes I had to make to work with the new API.

[rainergericke]

Your changes are ok, I was able to give my solution a much easier structure. Would be great if e.g. the number of vertices in VertexDraw could be set to a greater value than 65535, but if not the world will keep turning.

[robertosfield]

I don't understand the limit to 65535, vsg::VertexDraw has always used uint32_t mapping to the underlying vkCmdDraw parameters, nothing has changed there:

https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/nodes/VertexDraw.h

[rainergericke]

We have to set the number of vertices in VertexDraw, it is defined as:
uint32_t vertexCount = 0;
In VertexIndexDraw we have to set the numer of indices, defined as:
uint32_t indexCount = 0;
If the array sizes are greater than 65535, only a part of the arrays con be used.

[robertosfield]

65535 is a ushort/uint16_t not uint32_t.

Where is the chain is the limit to 65535 coming from?

I am not aware of any changes in v1.0.8 thought would force a constraint to uin16_t, this isn't a change I would consciously make so if something has crept in somewhere it will need fixing. At this point I don't have a lead to investigate so would appreciate any insights you can provide on what you think is introducing this limit.

[timoore]

We have to set the number of vertices in VertexDraw, it is defined as: uint32_t vertexCount = 0; In VertexIndexDraw we have to set the numer of indices, defined as: uint32_t indexCount = 0; If the array sizes are greater than 65535, only a part of the arrays con be used.

You might be getting confused by behavior of a specific loader, but the indices supplied to VertexIndexDraw can be uint32_t.

[rainergericke]

Sorry I mixed something up! You are right.

[robertosfield]

So is v1.0.8 OK then?

[rainergericke]

Yes, it is!

[robertosfield]

I('ll drink to that :-)