[Mesa-dev] [PATCH 5/8] vbo: Use static const VERT_ATTRIB->VBO_ATTRIB maps.

[Mathias Fröhlich]

Hi Brian,

On Wednesday, 31 January 2018 17:55:37 CET Brian Paul wrote:
> I wonder if it wouldn't be better to just use a small inline fnction to 
> do this mapping.  It may be faster to evaluate than to do a memory lookup.
> 
> static inline enum vbo_attrib
> vbo_attribute_alias_map(enum vp_mode mode, gl_vert_attrib attrib)
> {
>     STATIC_ASSERT(VBO_ATTRIB_GENERIC0 == VERT_ATTRIB_GENERIC0);
>     if (mode == VP_SHADER) {
>        return (vbo_attrib) attrib;
>     }
>     else {
>       const int offset = VBO_ATTRIB_MAT_FRONT_AMBIENT - VBO_ATTRIB_GENERIC0;
>       return attrib < VERT_ATTRIB_MAT0 ? (vbo_attrib) attrib
>           : VBO_ATTRIB_MAT_FRONT_AMBIENT + offset;
>     }
> }

I know, data cache footprint. Well, I don't exactly know and I believe that 
this will be dependent on the cpu used finally. The downside of your branch 
based approach is that we do that if relatively often at least as of today 
where we walk all VERT_ATTRIB_MAX entries. Branch prediction will then 
probably fix that. OTOH also branch prediction has some kind of cache that is 
trashed. And there is a lot more of these kind of thoughts that can be put 
into such arguments...

So to say, I am not finally tied to the array approach - not at all. But The 
calling code will change at least once if not more often to have reviewable 
and bisectable patches. I would prefer to do this kind of optimizations with 
the final version that will stand for some time. Especially because in that 
version of the map use we may have different opportunities to do optimizations 
than what we see now.
The series is done in a way not to regress speed to the previous version, but 
fully optimizing each intermediate step will be difficult.

best

Mathias