Message ID | CAPM=9txVydO1fy8sEwVXRZF0zPfWwLYrk-UnGeKhRCEvrW4B7Q@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [git,pull] drm fixes + one missed next for 5.16-rc1 | expand |
On Thu, Nov 11, 2021 at 7:25 PM Dave Airlie <airlied@gmail.com> wrote: > > I missed a drm-misc-next pull for the main pull last week. It wasn't > that major and isn't the bulk of this at all. This has a bunch of > fixes all over, a lot for amdgpu and i915. Ugh. The i915 conflict was trivial, but made me aware of that absolutely disgusting "wbinvd_on_all_cpus()" hack. And that thing is much too ugly to survive. I made my merge resolution remove that disgusting thing. That driver is x86-only anyway, so it all seemed completely bogus in the first place. And if there is some actual non-x86 work in progress for i915, then that wbinvd_on_all_cpus() needs to be replaced with something proper and architecture-neutral anyway, most definitely involving a name change, and almost certainly also involving a range for the cache writeback. Because that "create broken macro on other architectures" thing is *NOT* acceptable. And I sincerely hope to the gods that no cache-incoherent i915 mess ever makes it out of the x86 world. Incoherent IO was always a historical mistake and should never ever happen again, so we should not spread that horrific pattern around. Linus
The pull request you sent on Fri, 12 Nov 2021 13:25:30 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-11-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/304ac8032d3fa2d37750969cd4b8d5736a1829d9
Thank you!
On Sat, 13 Nov 2021 at 06:16, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, Nov 11, 2021 at 7:25 PM Dave Airlie <airlied@gmail.com> wrote: > > > > I missed a drm-misc-next pull for the main pull last week. It wasn't > > that major and isn't the bulk of this at all. This has a bunch of > > fixes all over, a lot for amdgpu and i915. > > Ugh. > > The i915 conflict was trivial, but made me aware of that absolutely > disgusting "wbinvd_on_all_cpus()" hack. > > And that thing is much too ugly to survive. I made my merge resolution > remove that disgusting thing. > > That driver is x86-only anyway, so it all seemed completely bogus in > the first place. > > And if there is some actual non-x86 work in progress for i915, then > that wbinvd_on_all_cpus() needs to be replaced with something proper > and architecture-neutral anyway, most definitely involving a name > change, and almost certainly also involving a range for the cache > writeback. > > Because that "create broken macro on other architectures" thing is > *NOT* acceptable. > > And I sincerely hope to the gods that no cache-incoherent i915 mess > ever makes it out of the x86 world. Incoherent IO was always a > historical mistake and should never ever happen again, so we should > not spread that horrific pattern around. i915 will no longer be x86-64 only in theory, since Intel now produces PCIe graphics cards using the same hw designs. These shouldn't AFAIK require the same incoherent architecture, though PCIe unsnooped transactions are a thing in the real world. The thing is the same driver needs to build/work for the integrated and discrete cards, hence this hack, but I'm sure someone can Intel can do better. I'll leave it to Daniel to figure out who/how. Dave.
On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie <airlied@gmail.com> wrote: > > i915 will no longer be x86-64 only in theory, since Intel now produces > PCIe graphics cards using the same hw designs. Well, at least in my tree, it still has the "depends on X86", along with several other x86-only things (like "select INTEL_GTT", which is also x86-only) So by the time that non-x86 theory becomes reality, hopefully the i915 people will also have figured out how to do the cache flushing properly. And hopefully that "do it properly" ends up being simply that the particular configuration that ends up being portable simply doesn't need to do it at all and can statically just not build it, sidestepping the issue entirely. Fingers crossed. .. of course, I'm also sure some clueless hardware engineer is still convinced that non-coherent IO is the way to go for graphics, and that doing cross-CPU IPIs to write back all caches is somehow still a valid model. Because some people were still convinced about that not _that_ long ago. Hopefully reality (perhaps in the form of Apple) has caused people to finally reconsider. Linus
On 11/14/21 22:19, Linus Torvalds wrote: > On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie <airlied@gmail.com> wrote: >> i915 will no longer be x86-64 only in theory, since Intel now produces >> PCIe graphics cards using the same hw designs. > Well, at least in my tree, it still has the "depends on X86", along > with several other x86-only things (like "select INTEL_GTT", which is > also x86-only) > > So by the time that non-x86 theory becomes reality, hopefully the i915 > people will also have figured out how to do the cache flushing > properly. > > And hopefully that "do it properly" ends up being simply that the > particular configuration that ends up being portable simply doesn't > need to do it at all and can statically just not build it, > sidestepping the issue entirely. > > Fingers crossed. For non-x86 / discrete graphics, plan is only coherent mappings, although the "Just not build it" part hasn't been properly figured out yet I guess. But point taken. Thanks, /Thomas
On Mon, Nov 15, 2021 at 08:18:53AM +0100, Thomas Hellström wrote: > On 11/14/21 22:19, Linus Torvalds wrote: > > On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie <airlied@gmail.com> wrote: > > > i915 will no longer be x86-64 only in theory, since Intel now produces > > > PCIe graphics cards using the same hw designs. > > Well, at least in my tree, it still has the "depends on X86", along > > with several other x86-only things (like "select INTEL_GTT", which is > > also x86-only) Yeah it's work in progress and 12+ years of x86 pile up high&deep aren't easy to fix. So please assume the depends on X86 is gone already (and select INTEL_GTT is optional, it's only needed for igfx older than about 8 years or so), but we can't do that yet because all the build boots would run out of air screaming so much :-) > > So by the time that non-x86 theory becomes reality, hopefully the i915 > > people will also have figured out how to do the cache flushing > > properly. > > > > And hopefully that "do it properly" ends up being simply that the > > particular configuration that ends up being portable simply doesn't > > need to do it at all and can statically just not build it, > > sidestepping the issue entirely. > > > > Fingers crossed. > > For non-x86 / discrete graphics, plan is only coherent mappings, although > the "Just not build it" part hasn't been properly figured out yet I guess. > But point taken. Yeah for non-x86 it'll be standard dma-api all the way down. For x86 that ship sailed long ago, but also I'm not clear on why we added a new cache flush primitive for that instead of just continuing to use clflush like we've done since forever. For x86 integrated gpu we _know_ which cpu is there, clflush will exist. So any new horrors shouldn't be needed, not sure why a wbinvd_on_all_cpus slipped in. -Daniel