It’s been quite a time but nonetheless … I’d like to solve this 
Well, yes, it makes sense, but feels like a detour around what I’m really looking for, besides it puts another stress on the pipeline in terms of [0, 1] -> medium float conversion - the work I wanted to actually get done offline, as I’m trying to reduce the memory bandwidth while not hogging shaders with a single line of new code.
What I’m probably really proposing here is OpenGL extension which would solve the discrepancies between the type mappings of glVertex*** APIs and Shader code in such a way:
GL_MEDIUMP_FLOAT / GL_HALF_FLOAT -> mediump float
While also specifying the bit representation of these types like GL_MEDIUMP_FLOAT -> 1s.5e.10m encoding IEEE 754-2008. The GL_LOWP_FLOAT format is totally obscure here … These things are by spec vendor dependent.
In 3.4. Promote Calculations up ‘The Chain’ chapter of the PowerVRSGX performance recommendations is mentioned pre-baking, while in chapter 4.3. Data Types we get:
Vertex shaders always expect attributes to be of the type ‘float’, this means that all types except ‘float’ will require a conversion. This conversion is performed in the USSE pipeline and costs a few additional cycles; thus the choice of attribute data type is a trade-off between shader cycles, bandwidth/storage requirements and precision. It is important that type conversion is considered as bandwidth is always at a premium.
Precision requirements should be checked carefully, the ‘byte’ and ‘short’ types are often sufficient, even for position information. For example, scaled to a range of 10m the ‘short’ types give you a precision of 150 μm. Scaling and biasing those attribute values to fit a certain range can often be folded into other vertex shader calculations, e.g. multiplied into a transformation matrix.
(what kind of float are we talking here? lowp, medium, high? or floats in general?)
Or is that part made slightly invalid by the chapter
4.6. Padding:
When vertex data is interleaved, each vertex should be aligned to a four byte boundary; when vertex data is not interleaved each element in each array of vertex data should be aligned to a four byte boundary.
Meaning that it doesn't really make sense to try to upload less than 4bytes per element/vertex? If that is right, then it really cannot be helped on this level but wait:
Let's say that I load my vertex data in the aforementioned 1s.5e.10m format and want to upload them to the GPU, so what can I do:
1 - Just convert them to full blown float32 at runtime, and let the driver do the rest.
2 - Do like you proposed in your post
(Option 1) is just plain wrong, since the only bandwidth I probably save here is
Storage ->
Memory, I guess that on-fly decompression of the vertex data using zlib/snappy would save more space while not wasting that much more cycles. The only justification for this is probably combining both compressed + half-float vertex data, that format would probably need to be taken with further care, since stuffing that many information bits into so tightly packed space makes the problem of high entropy apparent. (Option 2) Puts a burden on the runtime shader performance, also code needs to be updated in non-obvious ways, as well as the art pipeline.
We need
(Option 3).
TL;DR version:
I guess that all we need is having the names for the
mediump and
lowp types available in the
glVertex*** family of functions and making the OpenGL client state aware of them, since the server obviously already knows how to handle them. That solution would also work nicely in the the context that "The type is not merely a size hint I'm afraid, it is in fact a hard type definition ..."
Where can we call for an extension? :)
thanks, L.
EDIT: According to
this Japanese website :
PowerVR SGX unified fp32 fp16 fix10 fp32 fp16 fix10
PVR SGX543MP unified fp32 fp16 fix10 fp32 fp16 fix16?
The lowp is actually fix10, it seems to be in the Q10 format at least on my iPhone 4S:
```
const char * shader_names[2] = {"GL_FRAGMENT_SHADER", "GL_VERTEX_SHADER"};
const char * precision_names[6] = {"GL_LOW_FLOAT", "GL_MEDIUM_FLOAT", "GL_HIGH_FLOAT", "GL_LOW_INT", "GL_MEDIUM_INT", "GL_HIGH_INT",};
int range[2], precision;
printf("[X3D.PrecisionQualifiers.Dump] START --n");
for(int i = GL_FRAGMENT_SHADER; i <= GL_VERTEX_SHADER; ++i)
{
for(int k = GL_LOW_FLOAT; k <= GL_HIGH_INT; ++k)
{
glGetShaderPrecisionFormat(i, k, range, &precision);
printf("(%s %s) Precision: %i Range: [%i:%i]n", shader_names[i-GL_FRAGMENT_SHADER], precision_names[k-GL_LOW_FLOAT], precision, range[0], range[1]);
}
}
printf("[X3D.PrecisionQualifiers.Dump] END --n");
```
Which outputs:
```
[X3D.PrecisionQualifiers.Dump] START --
(GL_FRAGMENT_SHADER GL_LOW_FLOAT) Precision: 8 Range: [0:0]
(GL_FRAGMENT_SHADER GL_MEDIUM_FLOAT) Precision: 10 Range: [15:15]
(GL_FRAGMENT_SHADER GL_HIGH_FLOAT) Precision: 23 Range: [127:127]
(GL_FRAGMENT_SHADER GL_LOW_INT) Precision: 0 Range: [23:23]
(GL_FRAGMENT_SHADER GL_MEDIUM_INT) Precision: 0 Range: [23:23]
(GL_FRAGMENT_SHADER GL_HIGH_INT) Precision: 0 Range: [23:23]
(GL_VERTEX_SHADER GL_LOW_FLOAT) Precision: 8 Range: [0:0]
(GL_VERTEX_SHADER GL_MEDIUM_FLOAT) Precision: 10 Range: [15:15]
(GL_VERTEX_SHADER GL_HIGH_FLOAT) Precision: 23 Range: [127:127]
(GL_VERTEX_SHADER GL_LOW_INT) Precision: 0 Range: [23:23]
(GL_VERTEX_SHADER GL_MEDIUM_INT) Precision: 0 Range: [23:23]
(GL_VERTEX_SHADER GL_HIGH_INT) Precision: 0 Range: [23:23]
[X3D.PrecisionQualifiers.Dump] END --
```
