No GPU acceleration?And Raspberry Pi 3 probably will never get GPU acceleration on mainline, because they don't contribute much of their code upstream.
Not quite sure what the guy is going on about. All the VC4 MESA stuff is going upstream IRC. And that is the HW acceleration.
We really need to put an end to this persistent and pervasive myth that 64-bit data or 64-bit addressable memory can only be used by 64-bit architectures.
I think it has more to do with the issue that code bloat is now so big that it is too hard to support 32bit cpus.We really need to put an end to this persistent and pervasive myth that 64-bit data or 64-bit addressable memory can only be used by 64-bit architectures.
They just cannot be arsed to support it. Simple as. It requries double the testing because you are now running two different kernels. Its one of the reasons we still only have an official 32bit kernel - the support burden of the extra kernel.Gavinmc42 wrote: ↑Tue Apr 23, 2019 4:23 amI think it has more to do with the issue that code bloat is now so big that it is too hard to support 32bit cpus.We really need to put an end to this persistent and pervasive myth that 64-bit data or 64-bit addressable memory can only be used by 64-bit architectures.
Too much testing and debugging?
Much easier just to stick with one architecture on ARM- Aarch64.
So what are these things driving the 64bit wagon?
Windows, Linux Desktops, Android, Chromium, Firefox and ?????
Gaming, AI, ML, NN?
Things have been getting more complex and supporting ARMv6/7 as well just add to the complexity.
Anyone using Chromium on a Pi B+? How fast does it run?
What version is Chromium up to 72, 73?They just cannot be arsed to support it.
IMO mostly hype and marketing, the spreading of the myth that one needs a 64-bit architecture to use larger memory sizes, that one can't access more than 4GB RAM without moving to a 64-bit architecture.
Without some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?
I used machines like that (mainframes) from 40+ years ago, and it was considered a nuisance then.rpdom wrote: ↑Tue Apr 23, 2019 1:01 pm
Using LPA addressing in the kernel gives access to 64GB of RAM overall using a 32 bit kernel, but indiviual processes are limited to 4GB.jahboater wrote: ↑Tue Apr 23, 2019 12:34 pmWithout some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?
If you've got a 32-bit wide address bus then, no, it cannot access more than 4GB without mapping. But there's no reason the memory address bus width has to be 32-bit.jahboater wrote: ↑Tue Apr 23, 2019 12:34 pmWithout some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?
Code: Select all
uint32 adr = 0xFFFFFFFF; uint32 num = 0x12345678; *adr = num;
Code: Select all
uint64 adr = 0xFFFFFFFFFFFFFFF; uint64 num = 0x123456789ABCDEF; *adr = num;
I absolutely agree with that. It's the belief that "it can't be done" which is wrong.
I would tend towards agreeing with that, though the gain from widening the data bus and data paths isn't always as much as hoped for.
It seems entirely acceptable with most architectures doing that. There are few other options with anything larger than an 8-bit data bus for memory if you get 32-bit or 64-bit data coming back from memory no matter what you would like to get.jahboater wrote: ↑Tue Apr 23, 2019 1:32 pmI used machines like that (mainframes) from 40+ years ago, and it was considered a nuisance then.
No way that would be acceptable now, especially with modern computer usage.
Hardware shifters and barrel rollers in the pipeline or somewhere before or after the ALU for input, read-update-write for output. This would also apply for "int *" or any case where the memory bus is wider than the data width being written.
There is no myth in the 32 bit 2038 in the Linux kernel.hippy wrote: ↑Mon Apr 22, 2019 12:24 pm
So whatever you believe there is no solution to 32bit 2038 apart from a 64bit kernel and device.On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski <email@example.com> wrote:
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:
I talked to Arnd (I think - we were talking about all the crazy ABI's,
but maybe it was with somebody else) about exactly this in Edinburgh.
Apparently the main real use case is for extreme benchmarking. It's
the only use-case where the complexity of maintaining a whole
development environment and distro is worth it, it seems. Apparently a
number of Spec submissions have been done with the x32 model.
I'm not opposed to trying to sunset the support, but let's see who complains..
It's not a myth, but it's not an insurmountable problem either.
x32 was an attempt at making an ABI which ran the processor in 64 bit mode but had 32 bit pointers, as you say it didn't catch on.
You seem to be taking a post about dropping an obscure feature as evidence of the kernel dropping 32 bit support in general. That seems like rather a leap.
On the contrary 64 bit time on 32 bit systems is being worked on. It's not fundamentally much different from the way large file support was added years ago. It's taking time because it's not top of too many peoples priority list yet and because it needs to be done without breaking existing software.
No there's no myth there. The overflow of the 32-bits currently used is there, is going to happen, and will cause problems when it does if not resolved. It's as real as Y2K was. No one's denying that, no one's calling that a myth.
There may be no solution which Linus or some others are willing to provide but I am sure third parties will.
Looks like the wrong quote markup was edited in. If OP doesn't fix it go ahead and fix it yourself.