[Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

[Lauri Kasanen]

On Fri, 03 Jan 2014 01:37:22 +0100
Andreas Hartmetz <ahartmetz at gmail.com> wrote:

> > 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?

It would greatly add complexity and thus runtime overhead. The type is
more than just one input, it would be around ~10 inputs more.

The other case is that simplifying it into one input means that all
paths will be tested by training data. With the full surface params, it
would be unlikely for all combinations to get tested, as even finding
apps that use rare combinations would be hard. Ie - less chance of bad
regressions.

> 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.

Assuming wide enough training data, those bad results won't happen. I
agree though, Real World (tm) tends to interfere, but let's try to
minimize that ;)

> You also want good performance when you execute something for the
> first time (without training) because the first impression is so
> important.

This is a static network, ie no runtime changes, in order to minimize
runtime overhead and code complexity in mesa/kernel.

> 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 :)

In three months' time, we'll see :)

- Lauri