No SSBO for vertex shaders?

[Const.me]

Here’s GLES code of the vertex shader:

Code: Select all

struct sDrawCallData
{
	vec4 something;
	vec4 somethingElse;
};
buffer drawCalls
{
	sDrawCallData drawCallsPayload[];
};

Linker output:

error: Too many vertex shader storage blocks (1/0)

So the SSBO limit is 0, i.e. they are not available whatsoever.

Is there some workarounds to make buffers work? Or should I replace that data structure with a 2D float4 texture and use texelFetch() to read my 2 values? Or should I replace, or supplement, vertex shader with a compute shader?

P.S. The data in that buffer is dynamically updated by CPU every frame. That’s why I would prefer the buffer, especially given the GPU reports support of this extension: https://www.khronos.org/registry/OpenGL ... torage.txt

Update: the API reports GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS = 0 and GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 16. If true, it means vertex shaders can’t read from buffers, but they can read from textures, up to 16 of them.

[txenoo]

That is correct, SSBO are currently not available in geometry stages.

Here is the commit in Mesa with the explanation of the current status.

Code: Select all

commit d23b47fda57f63607a134f0ae31397c4ff983ec1
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Apr 22 11:24:55 2019 -0700

    v3d: Disable SSBOs and atomic counters on vertex shaders.
    
    The CTS fails on
    dEQP-GLES31.functional.shaders.opaque_type_indexing.atomic_counter.*vertex
    when they are enabled, due to the VS being run for both bin and render.  I
    think this behavior is expected to be valid, but I can't find text in
    atomic counters or SSBO specs saying so (the closed I found was in
    shader_image_load_store).  Just disable it for now, since the closed
    source driver doesn't expose vertex atomic counters/SSBOs either.

[Const.me]

That’s unfortunate. I don’t need any atomic counters, I just need to read from a buffer.

Apparently, textures don’t have the precision: viewtopic.php?f=68&t=266652
6 out of 8 of my floats are 3x2 transformation matrix, I need all 32 bits of the precision for them.

Using a uniform buffer for now, but the limit is small, 64kb, only enough for 4k vectors.

P.S. That’s 13 years of lag behind Windows: HLSL has Buffer<float4> since D3D 10.0…

[Brian Beuken]

hmm that is unfortunate, I am working on some tutorials for compute shaders and wanted to use the RPi4 for that.
Is it likely to be fixed soon, I know driver dev is an ongoing process.

Also does anyone know what the status is on OpenGLES3.2?


Edit, I have found that this is not just Rpi4 that has this issue, quite a few 3.1 GPU's on SBC's also report 0 for GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS 's available
So its more a mesa issue than anyting specific to Rpi4 I suspect, Jetson Nano with its Nvidia supplied drivers gives better results. But I guess since they make the GPU, they're not having to guess on how things work
This GPU can support :32 Textures
This GPU can support :16 vertex SSBO

[Brian Beuken]

Arise old thread... I have updates

I found I was reading some of the API info wrong and this is what we have on the pi

This GPU supports 16 Texture units
This GPU supports 0 SSO
max global (total) work group counts x:65535 y:65535 z:65535
max local (in one shader) work group sizes x:256 y:256 z:256
max local work group invocations 256


so still no SSBO's bit we can certainly play with the shaders.. has anyone any examples?

[RedMarsBlueMoon]

so still no SSBO's bit we can certainly play with the shaders.. has anyone any examples?

Did you aver have any luck getting something like this to work? I recently found this extension supposedly supported,
'GL_ARB_shader_storage_buffer_object'

but now when I try to set up a fragment shader it tells me,

Code: Select all

ERROR::SHADER::FRAGMENT::COMPILATION_FAILED
0:2(12): error: extension `GL_ARB_shader_storage_buffer_object' unsupported in fragment shader

[Brian Beuken]

No I had to give up on it but wasn't aware of that extension I might try it out later.

Edit EDIT.. I just twigged, GL_ARB is an OpenGL extension prefix... remember the Pi's OpenGL is quite a low feature version somewhere around 2.1-2.3 it probably won't support any advanced extensions like that,
I looked it up, you need OpenGL4.0+

OpenGL 4.0 (either core or compatibility profile) is required.

OpenGL 4.3 or ARB_program_interface_query is required.

This extension is written against the OpenGL 4.2 (Compatibility Profile)
Specification.

Another good reason to useOpenGLES3.0 is that it has a lot more features and extension than OpenGL on the Pi.


edit, I don't think the Pi supports that extension, here's what the Pi 400 reports.

the Pi4/400 extensions, not all are certain to function but it claims to have them
:GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture
GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil
GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer
GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync
GL_OES_vertex_array_object GL_EXT_occlusion_query_boolean GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers
GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range
GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_OES_depth_texture_cube_map GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_color_buffer_float GL_EXT_sRGB_write_control GL_EXT_separate_shader_objects GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix
GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_draw_elements_base_vertex GL_EXT_primitive_bounding_box GL_EXT_shader_io_blocks
GL_EXT_texture_border_clamp GL_EXT_texture_norm16 GL_KHR_context_flush_control GL_NV_image_formats GL_OES_draw_elements_base_vertex
GL_OES_primitive_bounding_box GL_OES_shader_io_blocks GL_OES_texture_border_clamp GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array
GL_EXT_buffer_storage GL_EXT_float_blend GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_OES_EGL_image_external_essl3 GL_OES_shader_image_atomic
GL_MESA_shader_integer_functions GL_KHR_parallel_shader_compile GL_MESA_framebuffer_flip_y GL_EXT_texture_query_lod

[Brian Beuken]

My collegue Jacco Bikker who's an expert in ray tracing/marching systems has recently been converted to try out things on the Pi4, he's manged to get this going so far
https://twitter.com/i/status/1366466220329959430

he's going to look into the compute shaders shortly as he's certain he can offload much of the computing to them.... given his expertise on these things I'm going to wait and see how he does,.

[RedMarsBlueMoon]

Niiice very cool voxel demo your friend did for the Pi!

So the reason I thought it seemed supported on my Pi4b Raspbian was that I got a positive result from doing,

Code: Select all

> glxinfo | grep GL_ARB_shader_storage_buffer_object

Glxinfo lists a lot of extensions. So you're thinking glxinfo might not be right? I don't know myself maybe that's not a reliable tool then?

[Brian Beuken]

Yeah he's pretty amazing at stuff like that, I'm really looking forward to getting him to show me how to get the more out of compute shaders.

Can't comment on the validity of GLX info, but I do know the Pi's version of OpenGL is bascially 2.1 and that feature requires OpenGL4 so ....yeah maybe not to reliable on the reporting side.

The Pi4 itself does not report it has any ARB extensions (it wouldn't since ARB are GL not GLES) when you interrogate the system for its OpenGLES3.1 extensions so I'm guessing its just not there.

[RedMarsBlueMoon]

The Pi4 itself does not report it has any ARB extensions (it wouldn't since ARB are GL not GLES) when you interrogate the system for its OpenGLES3.1 extensions so I'm guessing its just not there.

Could I ask how you're listing the gl extensions/ capabilities?
I'd love to know a more reliable way of doing that.

[Brian Beuken]

sure thats quite easy you can interrogate the GPU with a range of things like this from within a C++ project


printf("This SBC supports version %i.%i of EGL\n", majorVersion, minorVersion);
printf("This GPU supplied by :%s\n", glGetString(GL_VENDOR));
printf("This GPU supports :%s\n", glGetString(GL_VERSION));
printf("This GPU Renders with :%s\n", glGetString(GL_RENDERER));
printf("This GPU supports :%s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));


and also like this to get specific values that return a number
glGetIntegerv(GL_MAX_TEXTURE_SIZE, &t);
printf("This GPU MaxTexSize is :%i\n",t);
glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, &t);
printf("This GPU supports %i Texture units\n", t); // pi4 16

glGetIntegerv(GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS, &t);
printf("This GPU supports %i SSO \n", t); // pi4

getting the extensions is simply a matter of calling
printf("This GPU supports these extensions :%s\n", glGetString(GL_EXTENSIONS));

This is when set up as OpenGLES2/3.0 I don't know what it will return if you run in in OpenGL, which is not really the Pi's natural GPU support.

[RedMarsBlueMoon]

Awesome thank you!
There's so many different aspects to this whole Gl/gpu side its hard to know which applies.

[Brian Beuken]

My only real advice is to avoid OpenGL, its not really what the gpu is designed to do, the drivers do what they can when there are direct correlations, and thats quite effecitve but OpenGL and OpenGLES diverge on certain ways of doing things, and then you have the ES system or the CPU emulating OpenGL commands and thats very variable. Even though technically amazing,.

But run it as a pure OpenGLES3.1 GPU and its a beast of a system.

[RedMarsBlueMoon]

Thanks for the advice! I am actually using ES 3.1. My project is more of an Computer Vision/Sensing project and I now wanted to start converting a SLAM algo (ORB 2) to do a bunch of its calculations on the GPU as the Pi4s cpu seem a bit too weak to run it fast enough. At least for someone with my programming skill level.

[Brian Beuken]

Thanks for the advice! I am actually using ES 3.1. My project is more of an Computer Vision/Sensing project and I now wanted to start converting a SLAM algo (ORB 2) to do a bunch of its calculations on the GPU as the Pi4s cpu seem a bit too weak to run it fast enough. At least for someone with my programming skill level.

perfect then you have all the access you need to the GPU, but yeah the compute shaders sadly are not fully usable for that kind of work unless you can get them done in a texture in some way?

The Arm itself is no slouch, and if you can multi thread it can crunch a lot of content, you could also try looking into NEON, which is Arms version of SIMD that can improve a lot of calculations. Just compiling to use NEON where possible often gives a small boost, I have a thread on the most basic use of it on my site, I never really full explored it though as I don't find I need to get that stressed about the CPU's basic performance, its always the GPU that I needed to push.

http://www.scratchpadgames.net/forums/s ... light=neon

If you are mathimatically minded though you can really push the NEON coding to get massive gains in speed.

[RedMarsBlueMoon]

Cheers for the info! Funnily the slowest part of the ORB slam algorithm is the feature detection called 'FAST'. And I found a Git project with a guy that had done a Neon version of Fast which worked on the Pi. He had some of the other parts done for Neon too.
Btw, when I said 'my level of programming skill I meant my *low* level of skill ! But I then started to do my own shader version of Fast only to realize it was Hard. But then just recently I found some shader code that does it. Problem is ideally you'd need a fair stretch of that full algo to be on the GPU in that case as it needs to keep referencing the image/textures.
What I liked about using the gpu was not just to get it faster it was also that I would offload the cpu at the same time for a sort of double gain impact.
Anyway, that's sort of where I ended. I'm now set my PC up for dual boot to run Linux on it and am planning to try streaming the images from the Pi to the PC to do the heavy lifting there and then send results back over local wifi. At least while I'm exploring.

EDIT: Ive also found people who use a trick to convert SSE accellerated code to Neon and there's a few slam systems on git that use that. It only needs to include a single header called something like sse2neon.h

[Brian Beuken]

So my collegue Jacco, did some testing on the compute shaders to port his ray caster, and found the performance to be very poor, much less than the CPU.. so he isn't going to use compute shaders in his voxel engine... no benefit.

hmmm might be another case of just because you have something doesn't mean you should use it.

[Brian Beuken]

So having established that compute shaders on the Pi4, are painfully slow and it would be easier to set up an ARM thread based job manager....

Does anyone have any valid uses for them? especially if you are also doing some intensive rendering?

I'm adding a section on setting up and using compute shaders in my book, but I am really struggling to think of any valid reasons to use them when they are so ineffective.