[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <87h8k7h8q9.fsf@linux.ibm.com>
Date: Mon, 06 Aug 2018 11:26:22 -0300
From: Tulio Magno Quites Machado Filho <tuliom@...ux.ibm.com>
To: Florian Weimer <fweimer@...hat.com>,
Mikulas Patocka <mpatocka@...hat.com>,
Andrew Pinski <pinskia@...il.com>
Cc: Richard Earnshaw <Richard.Earnshaw@....com>,
ard.biesheuvel@...aro.org,
Ramana Radhakrishnan <ramana.gcc@...glemail.com>,
thomas.petazzoni@...e-electrons.com,
GNU C Library <libc-alpha@...rceware.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>, linux@...linux.org.uk,
LKML <linux-kernel@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
Florian Weimer <fweimer@...hat.com> writes:
> On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
>> There's plenty of memcpy's in the graphics stack. No one will be rewriting
>> all the graphics drivers because of tiny market share that ARM has in
>> desktop computers. So if you refuse to fix things and blame everyone else,
>> you can as well announce that you don't want to have PCIe graphics on ARM
>> at all.
>
> The POWER toolchain maintainers said pretty much the same thing not too
> long ago. I wonder how many architectures need to fail until the
> graphics stack is finally fixed.
Unfortunately, it is not just the graphics stack.
This is being used in other userspace programs that benefit from GPUs and
accelerators.
But can we say they're are nonportable programs?
I'm not convinced yet.
--
Tulio Magno
Powered by blists - more mailing lists