Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Source ARM userland

raspberrypi.org

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Open Source ARM userland

#31

Post by makomk »

hermanhermitage wrote: post #21
nitrogen wrote: post #16

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.

It certainly appears so, though that didn't stop Liz from spreading misinformation as usual when one of the developers of an actual open-source driver for an ARM GPU correctly pointed this out: http://www.raspberrypi.org/archives/2221#comment-34981

The RasPi foundation is staying as classy as ever.

Re: Open Source ARM userland

#32

Post by hermanhermitage »

nitrogen wrote: post #25
hermanhermitage wrote: post #21

Earlier quoted context omitted.

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 R…

It's possible to splice into the current blob by using /dev/mem to access the GPU partitioned memory. This lets you hot patch the VideoCore firmware (quite tricky as its running ThreadX OS), or you can hunt down QPU fragments generated by shaders.

I have a plan to release an Architecture/Programming guide and will be recruiting more hands shortly for tools like LLVM etc. But today let's celebrate the great work the foundation have done opening up the user land!

Re: Open Source ARM userland

#33

Post by rcgs »

damian2000 wrote: post #27
ekianjo wrote: 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.

This mirrors my experience for Element 14 in the UK; ordered on the 11th and received on the 18th.

Re: Open Source ARM userland

#34

Post by hermanhermitage »

makomk wrote: post #31
hermanhermitage wrote: post #21

Earlier quoted context omitted.

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.

It certainly appears so, though that didn't stop Liz from spreading misinformation as usual when one of the developers of an actual open-source driver for an ARM GPU correctly pointed this out: http://www.raspberrypi.org/archives/2221#comment-34981 The RasPi foundation is staying as classy as ever.

Sour grapes from Luc I would say. The Lima project is tainted by breaches of the Mali license agreement and side channel information leaked out despite NDA. They need to start again with a Chinese wall. (Edit: According to rumours in the pubs around ARM headquarters)

Re: Open Source ARM userland

#35

Post by makomk »

lucian1900 wrote: post #4

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

Absurdly precious in this case, given that it's just an RPC wrapper around the closed-source blob running on the GPU processor core which contains the real OpenGL ES driver. This reveals literally no technical details about the actual GPU hardware that the existing API didn't.

Re: Open Source ARM userland

#37

Post by astrodust »

jwn wrote: post #29

With such an open stack, could the Pi be used as part of a GPU password cracking cluster?

An exceedingly slow part. Ten Pi units together costing $350 would be absolutely dusted by a single $350 full-scale GPU.

A $350 video card would have upwards of 2000 shaders and would run at a much higher clock-speed. It's simply orders of magnitude faster at a price that's only one order of magnitude higher.

Re: Open Source ARM userland

#38

Post by ansible »

jwn wrote: post #29

With such an open stack, could the Pi be used as part of a GPU password cracking cluster?

With such an open stack, could the Pi be used as part of a GPU password cracking cluster?

From what hermanhermitage said above, I'd guess no. You've now got full access to the OpenGL API, but you don't have full access to the hardware running the binary blob which is what is running the OpenGL code.

Re: Open Source ARM userland

#39

Post by makomk »

jwn wrote: post #29

With such an open stack, could the Pi be used as part of a GPU password cracking cluster?

Not any more easily than before. Previously you had the full power of the OpenGL ES API to program the GPU with, but if you wanted to do anything that didn't fit into the API you were SOL. Now you're in exactly the same situation, because the "high-level interface" to the GPU firmware is just OpenGL ES with the context set-up and buffer management replaced by something nastier.

Re: Open Source ARM userland

#40

Post by makomk »

wladimir wrote: post #11
potkor wrote: post #8

What does the "userland" subset encompass? What's left in closed source blobs?

AFAIK everything that runs on the ARM is now open source. The firmware of the GPU itself could still be a blob. That's very cool, I hope NVidia follows suit wishful thinking .

Thanks to Nouveau reverse engineering, you can actually run a number of recentish OpenGL GPUs with a completely open source stack including even the GPU firmware itself.

Now, I guess NVidia could put a high-powered processor on their GPUs and move their entire OpenGL driver stack onto it as "firmware" so that they could claim their drivers were open source, but that doesn't seem like something they'd do.

Post reply on HN