Dissecting the Apple M1 GPU, part I

• ancient-3d-for-turboc

  5 11 0.0 C

Is this where I post the code I wrote twenty-five years ago to do 16-bit fixed-point 3D rendering? https://github.com/pjc50/ancient-3d-for-turboc

The target architecture was a 33MHz 486 PC running in "real" (ie sixteen-bit) mode. While hardware floating point was sometimes available (DX systems) it was quite slow.

• mesa

  39 1,155 9.8 C

  Discontinued Mesa 3D graphics library (read-only mirror of https://gitlab.freedesktop.org/mesa/mesa/)

  

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/...).

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!

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

Suggest a related project