diff options
author | Roland Scheidegger <[email protected]> | 2016-01-15 03:10:40 +0100 |
---|---|---|
committer | Roland Scheidegger <[email protected]> | 2016-01-15 20:13:45 +0100 |
commit | 03f66dfb4b399f078fc1bc99be1f0937ce981def (patch) | |
tree | ea4e10dd8dea6dae5b1ae78b63089cf438e525cc /src/mesa/drivers/dri | |
parent | 2f9a325b6ac1609a9986b4bee161610730da7da5 (diff) |
llvmpipe: ditch additional ref counting for vertex/geometry sampler views
The cleaning up was quite a performance hog (making pipe_resource_reference
the number two in profilers on the vertex path, and 3rd overall, with its
cousin pipe_reference_described not far behind) if there were lots
of tiny draw calls (ipers). Now the reason was really that it was blindly
calling this for all potential shader views (so 32 each for vs and gs) even
though the app never touched a single one which could have been fixed,
however I can't come up with a good reason why we refcount these. We've got
references, of course, in the sampler views, which should be quite sufficient
as we do all vertex and geometry shader execution fully synchronous.
(Calling prepare_shader_sampling for all draw calls even if there were no
changes looks quite suboptimal too, but generally we don't really expect vs/gs
shader sampling to be used much with llvmpipe, and there's even an early exit
if there aren't any views to avoid the "null loop" albeit it's now no longer
always trying to loop through all 32 slots. Maybe improve another time...).
Of course, if we manage to make vertex loads run asynchronously some day,
we need references again, but adding that back would be the least of the
problems...
Also only set LP_NEW_SAMPLER_VIEW for fragment sampler views. Nothing on the
vertex side depends on it (I suppose we'd really wanted a separate flag in
any case).
(Good for a 3% improvement or so in ipers under the right conditions.)
Reviewed-by: Jose Fonseca <[email protected]>
Diffstat (limited to 'src/mesa/drivers/dri')
0 files changed, 0 insertions, 0 deletions