On Mon, 21 Jan 2019 at 17:35, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>
> On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote:
> > > Until that happens we should just change the driver ifdefs to default
> > > the hacks to off and only enable them on setups where we 100%
> > > positively know that they actually work. And document that fact
> > > in big fat comments.
> >
> > Well, as I mentioned in my commit log as well, if we default to off
> > unless CONFIG_X86, we may break working setups on MIPS and Power where
> > the device is in fact non-cache coherent, and relies on this
> > 'optimization' to get things working. The same could be true for
> > non-coherent ARM systems, hence my approach to disable this hack for
> > cache coherent devices on non-X86 only.
>
> Do we break existing setups or just reduce performance due to the lack
> of WC mappings? I thought it was the latter.
Combining this check
#if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
return false;
...
#else
return true;
#endif
with the fact that the driver assumes that DMA is cache coherent, I'd
be surprised if this hardware works without the hack.
The optimization targets cache coherent systems where pushing data
through the cache into the GPU is wasteful, given that it evicts other
data and relies on snooping by the device. In this case, disabling the
optimization reduces performance.
My point is that it is highly likely that non-cache coherent systems
may accidentally be in a working state only due to this optimization,
and not because the driver deals with non-cache coherent DMA
correctly.
> The point is that
> even your check won't do what you actually said.
Well, it enables the optimization only for non-cache coherent devices.
How is that different from what I said?
> At lot of non-loongson
> mips platforms are not cache coherent.
You are assuming that whoever added that check cared about other MIPS platforms
> As are a lot of arm setups
> and all sparc64 ones for example. And chances that someone will
> hacks this file out in a random subsystem when adding news ports also
> is rather slim, so we'll remaing broken by default.
>
> That is why I want at very least: a whitelist instead of a blacklist
> and some very big comments explaining what is going on here.
ideally, we'd turn off this optimization entirely unless running on
x86. That would be my preference.
However, given the above re non-cache coherent systems, i am cautious.
> And in
> the mid to long term even drm really needs to learn to use the
> proper APIs :(
+1
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
