4 ms·

The Raspberry Pi 4 3D hardware has pretty extensive support for 16-bit floats. eg All 32-bit FP ops support "free" conversion from/to 16-bit float on input/outp

The Raspberry Pi 4 3D hardware has pretty extensive support for 16-bit floats. eg All 32-bit FP ops support "free" conversion from/to 16-bit float on input/output, and there are a few 16-bit float ops (eg multiply) which work on 16-bit vec2s (effectively giving double the throughput if they can be used). I don't know how well the Mesa driver supports any of that stuff though. Do you know if there was something specific that was slow?

bullen 6y ago
Aha, interesting, where did you read about that? I just modified my vertex and normal arrays to half floats and the performance went down 80%!!! Maybe the vc4-dri.so driver hasen't implemented it properly yet one year later? But does it still save the RAM? So the texture uvs could be accelerated? But most of the data is in vec3... (vertex and normal)
- mechanical_berk 6y ago
  While I do not believe Broadcom has released any documentation on the 3D hardware in the Raspberry Pi 4, you can figure out a fair amount by looking at the Mesa driver. In particular see the shader processor instruction packing code (https://github.com/mesa3d/mesa/blob/master/src/broadcom/qpu/qpu_instr.h https://github.com/mesa3d/mesa/blob/master/src/broadcom/qpu/...). For vertex arrays, while in theory the driver could load vec2/vec4 F16 attributes into the vertex shader as-is, AFAICT the Mesa driver does not attempt to do this; they get converted to F32 as they are loaded from main memory. There would be downsides to getting rid of this conversion... in particular the hardware does not support F32->F16 conversions when loading attributes, so the driver would have to recompile the shader if you switched the vertex arrays to F32 (or perhaps more likely recompile the shader when it realises you are using F16 vertex arrays rather than F32). In any case, the hardware does support zero overhead F16->F32 conversions when loading attributes, so you should not see a performance drop when switching vertex arrays to F16! The performance should go up slightly as less data needs to be loaded from main memory. If you're seeing an 80% performance drop something has gone terribly wrong!

bullen 6y ago

Aha, interesting, where did you read about that? I just modified my vertex and normal arrays to half floats and the performance went down 80%!!! Maybe the vc4-dri.so driver hasen't implemented it properly yet one year later? But does it still save the RAM? So the texture uvs could be accelerated? But most of the data is in vec3... (vertex and normal)

mechanical_berk 6y ago
While I do not believe Broadcom has released any documentation on the 3D hardware in the Raspberry Pi 4, you can figure out a fair amount by looking at the Mesa driver. In particular see the shader processor instruction packing code (https://github.com/mesa3d/mesa/blob/master/src/broadcom/qpu/qpu_instr.h https://github.com/mesa3d/mesa/blob/master/src/broadcom/qpu/...). For vertex arrays, while in theory the driver could load vec2/vec4 F16 attributes into the vertex shader as-is, AFAICT the Mesa driver does not attempt to do this; they get converted to F32 as they are loaded from main memory. There would be downsides to getting rid of this conversion... in particular the hardware does not support F32->F16 conversions when loading attributes, so the driver would have to recompile the shader if you switched the vertex arrays to F32 (or perhaps more likely recompile the shader when it realises you are using F16 vertex arrays rather than F32). In any case, the hardware does support zero overhead F16->F32 conversions when loading attributes, so you should not see a performance drop when switching vertex arrays to F16! The performance should go up slightly as less data needs to be loaded from main memory. If you're seeing an 80% performance drop something has gone terribly wrong!