Live data from Hacker News

Open Source ARM userland

raspberrypi.org

21–30 of 61 posts

Re: Open Source ARM userland

#21

I'm curious how much of the OpenGL stack lives on the GPU. Does anyone know how low- or high-level the interface to the Videocore is? (Yes, I could just dive into the official source code release and the unofficial reverse engineering project, but that would be an inefficient use of potentially hours, when someone in the know might be able to answer in minutes)

The GL calls are marshalled across to the VideoCore firmware. The VideoCore firmware has essentially a function for each GL entry point. The shader compiler is in the VideoCore firmware. The QPU code fragments are generated by a pull on a data flow representation in the firmware.

Re: Open Source ARM userland

#22
post #19
post #9

Earlier quoted context omitted.

Well maybe - http://www.phoronix.com/scan.php?page=news_item&px=MTIxM...

From what I can see in the referenced talk, Samsung will still only provide binaries for the graphics. https://www.youtube.com/watch?v=LyYXh1V8ov8#t=30m40s

That's a shame. It's something at least...

Binary drivers or binary GPU firmware? If the latter then Pi is in much the same place. (I would watch the video but am at work...)

Re: Open Source ARM userland

#23
post #6

OK good, now the blob?

This is a pretty dumb request. What are you going to do with a chunk of bits for a processor for which you don't even have a toolchain. There is nothing more to open source other than what is already there. Asking for 'the blob' is akin to asking for the firmware source to a hard disk. Even if you had it you could not do much with it.

Not really, IMHO.

What are you going to do with it? Who knows, we don't know what the capabilities are. I also have an instinctive dislike of the odd GPU-driven boot process where something open and hackable like u-boot could have been used.

Re: Open Source ARM userland

#24

Wow, this is big. Embedded vendors are particularly precious about their GPU drivers. Hopefully this is the start of a trend.

Having open drivers is further enhanced by the limited hardware models, it means more time to focus on getting the most out of the hardware instead of getting the stack to be compatible with different hardware all the time.

Re: Open Source ARM userland

#25

I'm curious how much of the OpenGL stack lives on the GPU. Does anyone know how low- or high-level the interface to the Videocore is? (Yes, I could just dive into the official source code release and the unofficial reverse engineering project, but that would be an inefficient use of potentially hours, when someone in the know might be able to answer in minutes)

The GL calls are marshalled across to the VideoCore firmware. The VideoCore firmware has essentially a function for each GL entry point. The shader compiler is in the VideoCore firmware. The QPU code fragments are generated by a pull on a data flow representation in the firmware.

Thanks! I suppose that's not too surprising; I've yet to hear of anybody open sourcing their core OpenGL implementation (is there even an open implementation other than Mesa?). It would be fun, in a sense, to have raw access to the VideoCore components without any existing firmware. Judging from this comment[0] of yours that I found on a Google search, I'm not the first to think so.

Now, as I've said before, if the RPi gets solid USB host and isochronous transfer support (for e.g. Kinect, USB audio devices), then it will be unbeatable.

[0] http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33&t=6...

Re: Open Source ARM userland

#26
post #6

OK good, now the blob?

This is a pretty dumb request. What are you going to do with a chunk of bits for a processor for which you don't even have a toolchain. There is nothing more to open source other than what is already there. Asking for 'the blob' is akin to asking for the firmware source to a hard disk. Even if you had it you could not do much with it.

Though I agree that the parent comment was unhelpful and a bit ungrateful, there is at least one good reason to want source code, especially for one-of-a-kind GPU processors. It's just plain interesting.

Asking for 'the blob' is akin to asking for the firmware source to a hard disk. Even if you had it you could not do much with it.

Play. Is that not enough? I'd love to experiment with hard drive firmware, toy with different caching algorithms, learn about the algorithms that convert between the analog signals at the heads and the data sent to the host, etc.

Re: Open Source ARM userland

#27
post #17

The raspberrypi looks better every day. The last major item on the to-do list appears to be the supply side.

Even the supply is getting better. They have been increasing the production rates and the delivery timings are getting shorter.

Just wanted to mention that the supply from Element 14 in Australia is outstanding. I put in an order for 2x model B's two weeks ago and received them both (512mb model) last thursday ... approx. an 8 day wait.

Re: Open Source ARM userland

#28
Although this is good news am I correct in assuming the boot loader is still closed source? I was hoping that this would enable an official OpenBSD port but if the boot loader is still closed source this probably won't happen.

Re: Open Source ARM userland

#30
post #17

Earlier quoted context omitted.

Even the supply is getting better. They have been increasing the production rates and the delivery timings are getting shorter.

Just wanted to mention that the supply from Element 14 in Australia is outstanding. I put in an order for 2x model B's two weeks ago and received them both (512mb model) last thursday ... approx. an 8 day wait.

I actually got my Pi from Element 14 Singapore in just two days. I’m surprised when I got the package. Maybe it's because the demand in my area (Hong Kong) is low.
Post reply on HN