[marcan_42]

And Nouveau has to work with dozens of Nvidia cards, not just one, and full of legacy nonsense. I'm fairly optimistic it won't take 5 years.

(Especially not to the point of having a composited desktop; long tail game compatibility is less of a critical thing since, well, there are next to no games for ARM Linux...)

[sweden]

If you are just planning to hack something to show some basic and buggy 2D rendering, 5 years might be realistic.

[reificator]

This talk was posted in another comment chain: https://media.ccc.de/v/33c3-7946-console_hacking_2016

This was 3 years after the hardware release, presented on substantially more locked-down (but x86 and PC-like GPU to be fair) hardware with a demonstration of Portal 2 running in real time. Presented by the person you are replying to. I'm also assuming there was no funding involved given the requirement to build an exploit just to boot anything on the PS4.

As an unabashed cynic myself: Your cynicism as someone uninvolved with the project is outweighed by the informed opinion of someone who has demonstrated ability in the field of porting linux to other platforms.

[marcan_42]

To be fair, as the author of that: that was mostly a job of reverse engineering what was weird/broken/different about the PS4's GPU, which is otherwise a standard Radeon. It was effectively adding support for a new Radeon variant chip of an existing GPU generation. There was definitely a deep dive into the platform and I reverse engineered the proprietary Radeon firmware CPU architecture in the process (which nobody had done before), though, so I think I get some credit for that. But e.g. the userspace side "just worked" after a few trivial library patches; AMD's entire userspace blob GL/Vulkan driver worked completely unmodified once the kernel side was fixed up.

This would be adding support for a completely different GPU, which is a whole different ballgame and order of magnitude of complexity.

That said, as many hours as went into the PS4 Linux project, it was a hobby thing and I'm pretty sure if you add up the hours spent on the GPU side it wouldn't hit one month's worth of full-time work. I'm also offering a whole different order of magnitude of time investment here.

[codetrotter]

If you get funding to do the Linux to Apple hardware port, have you considered streaming the whole process on e.g. Twitch?

Would be very interesting to watch everything from the sideline. And as a reason to do it, aside from being inspiring and educational to others, by live-streaming your work you will certainly be able to attract even more funding over time.

[marcan_42]

I don't think I'd do literally the whole process as that could get old and tiring quite quickly, but I am definitely considering doing streams when it makes sense and I'm in the mood, or maybe setting up a regular schedule, or something like that.

[tubs]

Somewhat responding to a twitter post you made, but the Apple GPU is absolutely not a legacy-free architecture: it still looks broadly (very broadly) similar to a PowerVR GPU, which I don't think anyone would claim is even remotely sane.

To give you some context for the scope of the task: with all the hardware documentation and close to 32 years (combined) experience with that specific architecture it took around two years to write a conformant Vulkan implementation. Not including the compiler, kernel driver, or firmware.

Source: I have worked both on PowerVR and Apple GPU drivers.

[marcan_42]

Thanks for the context. I know the GPU isn't going to become a fully compliant implementation on par with the e.g. Radeon drivers with only one person working on in in months.

That said, are you talking about a full graphics stack, or just the GPU-specific bits? Modern Linux graphics heavily emphasize code reuse across architectures, both on the kernel side and userspace side, which is completely different from how vendors typically do things.

The goalposts are quite different between having a fully compliant implementation that can deal with software that uses the GPU intensively (and hits all the corner cases properly), which is what Apple has to build, and being a usable desktop experience for Linux - having the whole stack be open source makes debugging things a lot easier too. Getting to full Vulkan compliance is definitely not going to be a one-person job. But we've seen fairly fast progress on GPU drivers going from triangles on the screen to simple game ports in some cases, with only one or two developers involved. I obviously don't have any yardstick for how the Apple GPU compares to everything else, but a priori, my hope is to be able to push things past the initial cliff to where the GPU starts being useful, and then of course other contributors can help improve support. In my experience, the initial hurdle in building a community project is often the hardest part, as a lot of people have no idea where to start supporting undocumented hardware (and I'm particularly good at doing black-box reverse engineering of this kind of stuff; I can claim a good 15 years+ of experience there myself). For example, once e.g. the shader ISA is documented and a PoC backend implemented, I expect people with more shader optimization experience than me to want to pitch in and make it faster.

Re firmware, I would expect to use Apple's (at least initially).

[sweden]

I know very well who marcan is and I also have quite some experience in this area. I know how challenging these kind of things are and I just didn't expand on my argument because it is a very ambitious project.

[marcan_42]

"Just 2D" isn't really a thing, given modern GPU usage is all based on fully programmable 3D pipelines anyway. What I mean is the endless frustrating job of debugging closed source game corner cases (and often outright game bugs) is less critical here, since those games won't exist for ARM anyway. If it gets to the point where X11 and Wayland, desktop environments, common widget toolkits, browsers, media players, etc work smoothly and stably and perform well, then a lot of people will be very happy already. The long tail will always be there to chip at, and that will take years (not like vendor drivers are bug-free on any OS either!), but it's not a blocking factor to a usable desktop Linux experience. Lower-hanging fruit first.