[Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)
Andreas Hartmetz
ahartmetz at gmail.com
Thu Jan 2 16:37:22 PST 2014
On Thursday 02 January 2014 10:56:45 Lauri Kasanen wrote:
> On Thu, 02 Jan 2014 05:57:46 +0100
>
> Andreas Hartmetz <ahartmetz at gmail.com> wrote:
> > On Wednesday 01 January 2014 16:58:46 Lauri Kasanen wrote:
> > > @@ -257,6 +258,7 @@ struct radeon_winsys {
> > >
> > > unsigned size,
> > > unsigned alignment,
> > > boolean use_reusable_pool,
> > >
> > > + boolean high_prio,
> > >
> > > enum radeon_bo_domain domain);
> > >
> > > struct radeon_winsys_cs_handle *(*buffer_get_cs_handle)(
> >
> > Something I have learned about schedulers is that binary priorities
> > are not a good deal. They kind of encourage special case hacks and
> > two code paths, they can do less than numeric priorities, and they
> > are not significantly easier to implement if you want to do it
> > correctly. This is not exactly a scheduler, but it seems similar
> > enough.
> > So I think a numeric value and >= 3 priorities would be better here,
> > then you could also start assigning priority by things like buffer size
> > or really any heuristic that can produce some number. Even such
> > heuristics are easier to write when you don't need to limit the result
> > to true / false.
>
> Hi Andreas,
>
> This boolean is just one component to be used in the final score (for
> the plan, see github.com/clbr/jamkthesis). It passes down information
> that's otherwise unavailable, ie whether the buffer's type means it
> should be more likely to stay in VRAM.
>
> The buffer's size and other factors (patch 3, VRAM size) also influence
> the score.
>
> The network won't care if it's a bool or an int, so the question is
> just whether having it an int would mean better decisions or not. What
> do you think?
>
When you use a neural network anyway, why would you even assign a
priority instead of just passing the buffer type and let the network
figure out the rest?
I am somewhat skeptical of the whole thing honestly, because
predictable and repeatable performance is what you need for
performance-critical applications, not getting close to optimal
results most of the time and bad results sometimes.
You also want good performance when you execute something for the
first time (without training) because the first impression is so
important. Resource planning isn't magic, you don't really need to
"give up and use a generic AI" to do it well.
I guess you can discover some tricks using that approach, but for a
final implementation you better incorporate those tricks into a more
traditional cache eviction algorithm.
Now I don't want to discourage you from doing that thesis, but I don't
expect that a neural network buffer placement optimizer will be
practical for shipping with Mesa. I would like to be proven wrong,
though :)
More information about the mesa-dev
mailing list