Live data from Hacker News

Tales of the M1 GPU

asahilinux.org

331–340 of 390 posts

Re: Tales of the M1 GPU

#331
post #309

Earlier quoted context omitted.

> They are written in a strange subset of C++ with its own inheritance system and currency classes. Can someone explain? Is there something other than DriverKit, which seems to be C++? https://developer.apple.com/documentation/driverkit

I suspect they’re either conflating things with ObjectiveC or FireBloom ( https://saaramar.github.io/iBoot_firebloom/ ) Both would sort of fit those descriptions I guess if one were to squint.

https://developer.apple.com/documentation/kernel/osmetaclass...

https://developer.apple.com/documentation/kernel/osarray

That kind of thing.

Re: Tales of the M1 GPU

#332
post #327

Earlier quoted context omitted.

They are written in a strange subset of C++ with its own inheritance system and currency classes. In NeXTStep they were written in ObjC, and probably should've stayed that way.

Just like UNIX kernel code is a strange subset of C. I always find strange how "kernel C" is C, even though ISO C would bork in kernel space, but doing a similar C++ subset is pointed out as not being C++.

I'd also call kernel C strange. Mostly justified, but there's no particular reason the memory allocation call with the same behavior as malloc() in IOKit isn't named malloc().

Re: Tales of the M1 GPU

#333
post #181

Earlier quoted context omitted.

Have to say as much as I want to watch their streams, I can't get passed the annoying voice.

Yeah... I was hoping to passively watch it, maybe gleam something but yeah. The other thing too, watching other people code is kind of not fun like George or Rene. More fun to see some screeching video with no actual info just the end result of a robot pissing in a cup. Also goes to show how much work goes into writing code/having some end result. Maybe it will get more exposure since there is a growing trend for vtu…

You don't like watching George? His coding streams always get me hyped enough to work on my own projects.

Re: Tales of the M1 GPU

#334
post #309

Earlier quoted context omitted.

I suspect they’re either conflating things with ObjectiveC or FireBloom ( https://saaramar.github.io/iBoot_firebloom/ ) Both would sort of fit those descriptions I guess if one were to squint.

https://developer.apple.com/documentation/kernel/osmetaclass... https://developer.apple.com/documentation/kernel/osarray That kind of thing.

Oh interesting. Thanks for the link

Re: Tales of the M1 GPU

#335
post #262

Half the comments here are talking about the vtuber herself. Who cares. It's been talked before. Just imagine if half the thread is discussing what gender she is. What I am interested in is the claims here https://asahilinux.org/2022/11/tales-of-the-m1-gpu/#rust-is-... . (what is it called if it comes with a proof?). The resident C/C++ experts here would have you believe that the same is possible in C/C++. Is that tr…

In C? No, not unless you write your own scaffolding to do it. In C++? Maybe, but you’d need to make sure you stay on top of using thread safe structures and smart pointers. What Rust does is flip this. The default is the safe path. So instead of risking forgetting smart pointers and thread safe containers, the compiler keeps you honest. So you’re not spending time chasing oddities because you missed a variable initia…

> What Rust does is flip this. The default is the safe path. So instead of risking forgetting smart pointers and thread safe containers, the compiler keeps you honest.

For what it’s worth, the same is true of Swift. But since much of the original Rust team was also involved with Swift language development, I guess it’s not too much of a surprise. The “unsafe” api requires some deliberate effort to use, no accidents are possible there. It’s all very verbose through a very narrow window of opportunity if you do anything unsafe.

Re: Tales of the M1 GPU

#336
post #326
post #262

Earlier quoted context omitted.

In C? No, not unless you write your own scaffolding to do it. In C++? Maybe, but you’d need to make sure you stay on top of using thread safe structures and smart pointers. What Rust does is flip this. The default is the safe path. So instead of risking forgetting smart pointers and thread safe containers, the compiler keeps you honest. So you’re not spending time chasing oddities because you missed a variable initia…

It would also have been possible in Ada, but of course it isn't cool.

The history of Ada kept it from getting widespread attention. Sometimes it’s just about the right time and place.

Plus there’s something to be said for cargo being a killer feature for rust. Easy build configuration , easy package management and access to a large ecosystem of libraries.

Between that and the book..:As steep a learning curve as the language itself has, the actual on-boarding process is way more accessible than many other compiled languages.

Re: Tales of the M1 GPU

#337

Half the comments here are talking about the vtuber herself. Who cares. It's been talked before. Just imagine if half the thread is discussing what gender she is. What I am interested in is the claims here https://asahilinux.org/2022/11/tales-of-the-m1-gpu/#rust-is-... . (what is it called if it comes with a proof?). The resident C/C++ experts here would have you believe that the same is possible in C/C++. Is that tr…

I have a lot of experience in C, a lot of experience in C++, and some experience with Rust (I have some projects which use it). My opinion is that it's true, and the other comments are good explanations of why. But I want to point out, in addition to those: There's a reason why Rust was adopted into Linux, while C++ wasn't. Getting C++ to work in the kernel would almost certainly have been way less work than getting Rust to work. But only Rust can give you the strong guarantees which makes you avoid lifetime-, memory- and concurrency-related mistakes.

Re: Tales of the M1 GPU

#338
post #30

Earlier quoted context omitted.

Porting what?

GPU driver. So that one can install Windows on Apple Silicon and get accelerated graphics.

The GPU driver is an important component for desktop users, but it's just one small part of what you need to bring Linux to these machines. There's a ton of work in all kinds of other areas, down to changes in the core of the kernel. A GPU driver for Windows won't do you any good without all those other drivers.

Re: Tales of the M1 GPU

#339
post #312

Earlier quoted context omitted.

Isn't it the opposite, though? https://twitter.com/marcan42/status/1582930401118806016

I might be wrong here, but I have always been under the impression that they are the same person. I didn't even realise that is was supposed to be a secret. Simple things like Lina en Marcan using the same hostname for the development machine (Raider), using the same IDE (Kate), using the same bash aliases (the one I like most if 'stfu' that appears to suppress terminal output), and a huge overlap of knowledge. Then…

[deleted]

Re: Tales of the M1 GPU

#340

Earlier quoted context omitted.

Assuming it is the case I don't think it's polite to share this information. I don't know their motivation for creating a separate public image, but I think we should respect their decision to do so by not connecting them.

The Linux kernel does not accept anonymous contributions due to legal reasons. https://www.kernel.org/doc/html/latest/process/1.Intro.html > It is imperative that all code contributed to the kernel be legitimately free software. > For that reason, code from anonymous (or pseudonymous) contributors will not be accepted. > All contributors are required to “sign off” on their code, stating that the code can be distribut…

I expect Asahi Lina to be more than happy to assign copyright to an appropriate entity to contribute it upstream.
Post reply on HN