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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
