mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-22 23:58:10 +02:00
8aa168eb8f
When we switched to 64bit rasterization, we could no longer use straight aligned loads for loading the plane data. However, what the code actually does for loading 3 planes, is 12 scalar loads + 9 unpacks, and then there's another 8 unpacks for the transpose we need (!). It would be possible to do the (scalar) loads of course already transposed (at least saving the additional unpacks), however instead just use (un)aligned vector loads, and recalculate the eo values, which is much less instructions (note in case of the triangle_32_3_4 case, the eo values are not even used, making the scalar loads + unpacks for them all the more pointless). This drops execution time of the triangle_32_3_4 function considerably, albeit it doesn't really make a measurable difference (for small tris we're essentially limited by vertex throughput in any case), for triangle_32_3_16 it's essentially noise (the loop is more costly than the initial code there). (I'm thinking about just ditching storing the eo values in the plane data, so could switch back to using aligned planes, however right now they are still used in the other raster functions dealing with planes with scalar code. Also not touching the ppc code, might not be that bad there in any case.) Reviewed-by: Brian Paul <brianp@vmware.com> |
||
|---|---|---|
| .. | ||
| compiler | ||
| egl | ||
| gallium | ||
| gbm | ||
| getopt | ||
| glx | ||
| gtest | ||
| hgl | ||
| loader | ||
| mapi | ||
| mesa | ||
| util | ||
| Makefile.am | ||
| SConscript | ||