Page 1 of 1

Re: First impressions and 'blobs'

Posted: Mon Mar 26, 2012 1:29 pm
by tez
First-time poster but long time lurker (and attendee at yesterdays' Beeb@30 event).

I was lucky enough to get the chance to 'hog' Raspberry Pi #7 (thanks andytuk!) and see how the thing performed.

* Bootup time is insanely fast - you can be in X within about seven seconds of power on (might even be faster if the rootfs was on NFS).
* X11/X Windows is *not* accelerated; was there any liaising with X.org to get a proper driver written for the device ?

Unsure whether the shipping kernel has kernel mode-setting (KMS) support but I'll have to nose through the Raspberry Pi Fedora kernel SRPM to see if that is the case as I don't think Debian has much to do with KMS anyway.

On a personal note, I would love to know if kexec() functionality works on the Raspberry Pi and if it is also possible to 'lock' the SD card controller into read-only mode until the unit is power-cycled.

I have sort of cooled off wanting one ASAP but while I will undoubtedly still order one, IMHO the existing product is still pretty rough around the edges and not really suitable for end users yet.

I very much enjoyed the talk that Eben gave and never got the opportunity to ask the one question I've wanted to ask since the topic of binary blobs reared its' ugly head - one gentleman in the audience did refer to the topic of 'open source vs. closed source' but for reasons of time, it didn't go any further than that.

The relationship between Broadcom and Raspberry Pi Foundation has always been very clear; employs a lot of the staff in their day jobs and provides chips at cost (or very near cost) to make the project actually viable.

That said...

I can accept the fact that the GPU firmware might as well remain closed source due to the intricate knowledge of the hardware required (in-house Broadcom expertise or NDA required!) but the intermediate bits such as the OpenGL libraries (libgl.so) on Linux will also be closed as well; it would be good to know if the Raspberry Pi Foundation (or Broadcom) would be happy for an OS vendor (such as FreeBSD/Haiku) to submit a buildsystem suitable for building modules for that system and someone with access to the source at Broadcom/Raspberry Pi Foundation compiles the libraries and then sends the binary version back to the submitter.

I think that 'direct access to the hardware' will need to come eventually in order for the platform to become the true successor to the Beeb; that computer was built from off-the-shelf parts and while you could use the manual that it came with, there was nothing to stop the hardcore folks from pulling datasheets from the relevant component manufacturers and 'hitting the metal' that way.

Eben hinted at this with the charming anecdote about his first encounter with the AMS mouse (sans mouse driver) - suspect all of us have been here at some point in our careers but most folk will only care about the current high-level access to the hardware which is available now and not the low-level access which those of us who read pinouts and datasheets used to enjoy.

From a commercial perspective, I do feel that Broadcom are well within their rights to protect their current revenue stream provided by the BCM2835 (the SoC used in the Raspberry Pi) and that the intermediate libraries have to remain closed source for the time being; however, when this particular chip has been superseded - possibly in 2 to 3 years time - it would be worth knowing sooner rather than later if Broadcom would be prepared to release the source to the binaries once the chip is no longer a viable revenue stream for the company.

It was only many years after the release of certain 8-bit and 16-bit microcomputers that coders really learned how to push the machines to their full limits (using undocumented features and even hardware bugs to do some really wacky stuff).

If the intention is to base a whole curriculum subject around this device, getting the kids interested is the primary driver here but the end goal is to stimulate them into becoming programmers to whatever degree that they are comfortable with (be that Scratch or even ARM assembler!) but also to encourage those with the urge to tinker and experiment at the hardware level into doing so.

Re: First impressions and 'blobs'

Posted: Mon Mar 26, 2012 1:51 pm
by abishur
Was the version you used Debian or the F-mix distro?

Re: First impressions and 'blobs'

Posted: Mon Mar 26, 2012 2:38 pm
by ukscone
Abishur said:


Was the version you used Debian or the F-mix distro?


i believe andytuk is using the debian rootfs as he found the fedora one too slow & had some i/o errors on his sd card when using it

Re: First impressions and 'blobs'

Posted: Mon Mar 26, 2012 3:14 pm
by tez
andytuk was running Debian 6.0 on #7

Re: First impressions and 'blobs'

Posted: Mon Mar 26, 2012 5:43 pm
by jamesh
There should be a new Debian out soon, which fixes some issues.

It's very unlikely that the code to the blob will be released when the 2835 goes end of line, simply because the Videocore 4 GPU in the chip WONT be end of line - it's used in lots of other chips as well. And the code base is ported forward to the next version of the Videocore - so the VC4 code is a superset of the VC3 code, so if and when the VC5 is made, the code on it will be a superset of the VC4 (probably)

It really isn't necessary to have access to this code to get the best from it. There are a lot of very good engineers at Broadcom trained to get the best from it, so the majority of optimisation is already done or being done. The datasheet already released gives information on all the rest of the stuff, and plenty of opportunity to dabble at the hardware level. To be honest the GPU is so complicated 'dabbling' isn't really possible. This isn't a 8 bit micro.

Yes, there are issues with drivers (camera, screen) which need to be on the GPU. Might be ways round that though.

It would be nice if the user land libs were OSS software though.

The X driver required would be a OpenGL (or VG) backend. I find it amazing that such a thing doesn't already exist, but apparently not. The Broadcom supplied OGL library is MESA compatible, so it shoudl just work if the backend was there.

Re: First impressions and 'blobs'

Posted: Mon Mar 26, 2012 8:43 pm
by tez
Hi James,

Understood on the re-working of code to support one generation to the next; this has at least two potential possible drawbacks though:

* Are optimizations made in one generation's 'fork' of the blob backported to previous generations if the hardware is capable of supporting it ? (are Broadcom into 'planned obsolescence' ?)

* Same for bugfixes ? (especially if Broadcom are no longer shipping the 2835 at that time)

I appreciate that the GPU is a complex piece of technology but the combined effort of developers to reverse-engineer a binary blob and release a clean-room implementation of an open-source driver with around 90% performance of the manufacturer's original blob is out there in the form of the Nouveau project who reversed NVIDIA's proprietary GPU driver.

There are those who will tinker with something purely because it is there and rip it apart just to see how it ticks.

Glad you agree on the userland libraries though - all the proprietary magic should happen in the GPU and the firmware itself.

Any communication between OS and hardware should be via open, documented interfaces and I don't doubt for one second that Eben is working hard to make this happen... never hurts to give a bit of gentle encouragement every once and in a while though

X11 defaulting to framebuffer is definitely going to hurt end user impressions of the Raspberry Pi and it won't be as simple as 'slap the OpenGL doo-hickey into the X server and go' - it needs to have a proper understanding of display constructs, 'dirty updates' and the like - which you simply don't get with a framebuffer or a rendering of a 2D desktop on a single OpenGL-backed surface.

If Broadcom don't have the engineering expertise to do this (as I admit that these are smartphone SoCs not specifically designed to run X11), it probably wouldn't be a bad idea to get a competent X.org developer to sign a Broadcom NDA, give them a developer board and let them do the stuff they do best - depending on whether they have to use any NDA-gained knowledge, the driver can either be open or closed - the worst case scenario is that Broadcom has to expose more GPU functionality via an open/documented means and that can't really be a bad thing.

The engineering costs would be a drop in the ocean to Broadcom and if the kernel interfaces exposed by the GPU firmware remain static across different Videocore versions; the driver can also be reused by other Broadcom customers across the whole range of BCMxxxx SoCs using this technology.

Re: First impressions and 'blobs'

Posted: Tue Mar 27, 2012 5:47 am
by jamesh
tez said:


Hi James,

Understood on the re-working of code to support one generation to the next; this has at least two potential possible drawbacks though:

* Are optimizations made in one generation's 'fork' of the blob backported to previous generations if the hardware is capable of supporting it ? (are Broadcom into 'planned obsolescence' ?)

* Same for bugfixes ? (especially if Broadcom are no longer shipping the 2835 at that time)

I appreciate that the GPU is a complex piece of technology but the combined effort of developers to reverse-engineer a binary blob and release a clean-room implementation of an open-source driver with around 90% performance of the manufacturer's original blob is out there in the form of the Nouveau project who reversed NVIDIA's proprietary GPU driver.

There are those who will tinker with something purely because it is there and rip it apart just to see how it ticks


Generally, optimisations are ported to where they are needed, if applicable to that generation, as are bug fixes. This happens a lot between customer branches - fixes done there get ported to main code, and vica versa. Same applies to VC generations, if necessary. Remember, we are professionals! This isn't some garage bodge job.

A clean room version running at 90% wouldn't be good enough - for example, 1080p30 encode would stop working. Also, there are about 1000 man years of work on the Videocore binary.....that from the people who designed the chip. Imagine how long a clean room version by non-experts would take.

The plan for X is to get the community to write something - there will be a prize I believe! However, I doubt access to the GPU will be available except via the libraries. You have OpenVG, OpenGLES and EGL to play with, that should be enough, but I am no expert. There are stalled projects out there trying to do this.

Re: First impressions and 'blobs'

Posted: Tue Apr 03, 2012 9:36 am
by ph
Hi James,

Thank you for you explanations. I look very much forward to evaluating the Raspberry Pi computer as a platform for our computing curriculum and very much hope it will work out fine by the time the educational version will be buyable in larger quantities. For the suitability of the device in most of my courses, it would be awesome if the engineers involved in the following 2009 work very happy to share their experience with the community or were allowed and willing to donate some code.

"GPU-based X server on top of EGL and OpenVG"
Abstract from Dongkyun Jeong, Kamalneet, Namin Kim, Soochan Lim, ICCE, pp. 1-2, 2009 Digest of Technical Papers International Conference on Consumer Electronics, 2009

http://doi.ieeecomputersociety.....09.5012187

"Based on GUI desktop environment, running PC-class applications with rich user experience has become popular in mobile devices. A window system is an essential component of GUI desktop. As a window system for mobile devices, we implemented X server on top of EGL and OpenVG. GPU-based X server described in this paper may serve as a standard model of a window system in future mobile devices because graphics operations can be accelerated with less power consumption."

I didn't buy the article cited above, though, and thus can not comment on the achievement and its useability for the RPi computer. Also, I could not find any other projects attempting a GPU-based X server on top of EGL and OpenVG on the internet. Is anybody here on the forum familiar with the state and useability of the implementation cited above for the Raspberry Pi computer?

Anyway, it will probably be a lot quicker, easier, and could yield the desired and needed results for the educational end user experience with the Raspberry Pi computer much better [imho, hopefully, I'm too pessimistic here], if the foundation was raising money from the community to award a prize for a professional implementation of an accelerated software stack, since both the required skills and talent in X11, EGL and OpenVG seem to be in short supply.

What other (stalled) projects (that you are reffering to in your above post) do already exist? Is the foundation or the Fedora-Remix-Team at Seneca College already in touch with them? Any estimates on how many person years this would take a community based effort? Is this going to be a realistic project at all?

Thank you very much indeed for what everything you have achieved to this end.

Best regards and wishes, Peter

Re: First impressions and 'blobs'

Posted: Tue Apr 03, 2012 9:55 am
by jamesh
That abstract you refer to was one of the projects I think I found when I was looking. I think someone may even have emailed one of the authors - not sure if any reply was received. Think I also found another project, but cannot remember where that was - sorry!

Eben has said in the past that a cash prize for a good X11 backend using OpenVG/GL would certainly be something the Foundation would consider!

I cannot say how long it would take to implement - I don't have enough experience in either X11 or OpenVG/GLES. perhaps someone else may know.....anyone...?

James

Re: First impressions and 'blobs'

Posted: Thu Apr 12, 2012 6:06 am
by piface

It would be nice if the user land libs were OSS software though.



While I accept the commercial desire for GPU code to be closed source (I use CS NVidia drivers on my development machine rather than the less capable OSS nouveau drivers) I see no justification for closed source going beyond that. Especially with the educational leaning that is at the heart of this project.

Wifi is another area where there is a defacto reality of the need to accept the use of CS binaries. I think that is regrettable but that's the way it is. Similarly, now even Debian has conceded to the use of closed source Wifi firmware binaries.

However, I do expect the interface to be OSS and chose to buy wifi hardware from manufacturers, like realtek, that provide that for linux.

The other area where this affects RP is SDcard as boot device. Again, this is close source, non disclosure, land. I think this is less desirable.

I have worked with Technologic Systems' ARM PCs and have avoided models that us SD for that reason.

I will have to check on the status of attempts to provide an open source SD driver for the linux kernel.




Re: First impressions and 'blobs'

Posted: Thu Apr 12, 2012 7:33 am
by AlArenal
It's somewhat sad to have such a powerful GPU and not really an open interface to explore its capabilities. Apart from the pure graphics part that core is basically a number cruncher and right now as we're speaking people, companies and organizations are building concepts, hardware and software for ARM-based supercomputers using GPUs. The EU is currently partly funding such a project in Barcelona. While I was investigating for an article I found out about NVIDIA's CARMA DevKit, ...

Now that I find an exciting topic for education! Ok, not so much for beginners, but using GPUs for .. well.. as the acronym says "general purpose" is really eciting stuff with a lot of potential. Getting into this topic may prove as a door opener once you feel educated enough to look out for a job.

With such hardware at your fingertips it's hard not to get frustrated because you cannot take advantage of all its capabilities. It's like owning a Porsche that's stuck in second gear.

Re: First impressions and 'blobs'

Posted: Thu Apr 12, 2012 7:52 am
by jamesh
I'm still bemused by this attitude. GPGPU computing is a very minor part  of the programming industry, and one not very easy to do. Yes, it would be nice to have that in addition, but in no way is it important to the Foundations cause.

With the libraries currently supplied with the Raspi you have access to all the 2D/3D capabilities of the GPU, you have access to the decode capabilities, you have HDMI. Future releases will provide encode and camera facilities. That's the vast majority (>95%) of the capabilities of the GPU being exposed. It's not like a Porsche stuck in 2nd gear. It's like having all the gears available, but not having the last 1cm of throttle pedal which 99% of people don't use anyway.

What it comes down to – if the product doesn't do what you want, don't buy it. It's very simple – look on the Raspi as a device with the published feature set, not as a device that cannot do some stuff you think it ought to.

Re: First impressions and 'blobs'

Posted: Thu Apr 12, 2012 8:08 am
by AlArenal
You're right, GPGPU stuff isn't for everyone. Maybe in a way like home computers got used for gaming in 99% of cases. But I'm pretty sure there's a lot of people around here that started this whole thing that were not just into gaming and using, but instead wanted to turn each and every bit of what they had at hand and find out what they could do with it. People do all kinds of amazing stuff with hardware noone ever imagined. Didn't someone just write a MP3 player on a C-64 (saw it on YouTube)?

Not everybody is like that and only a handful people will end up in jobs doing such low level stuff. But isn't this all about building a better foundation in education, may it be in schools or at home? Isn't it about finding out abut limits and then pushing them even harder?

I'm not saying the Pi has to have a quadcore ARM with some AMD or NVIDIA GPU attached and a bundled CUDA and / or OpenCL SDK. I'm just saying this little cutie can do more than 80/20 and it would be great if there was a way to unleash the dragon…

Re: First impressions and 'blobs'

Posted: Thu Apr 12, 2012 9:23 pm
by arm2
piface said:



It would be nice if the user land libs were OSS software though.



While I accept the commercial desire for GPU code to be closed source (I use CS NVidia drivers on my development machine rather than the less capable OSS nouveau drivers) I see no justification for closed source going beyond that.


AIUI it doesn't.  What do you mean?

But it is a moot point as Broadcom are not going to release the sources, as has been said many times. They have no educational remit, that is the Foundations remit.

If you can't live without the sources, use something else that does, they are out there, just not at the price/performance of an R-Pi

Re: First impressions and 'blobs'

Posted: Thu Apr 12, 2012 9:56 pm
by nullstring
Nevermind.

Re: First impressions and 'blobs'

Posted: Thu Apr 12, 2012 10:39 pm
by bobc
Well, a kid at our school was told not to bother with assembler, because it was too complicated for him to understand, and anyway he didn't need to know it. Fortunately he ignored that advice, and learned assembler by himself.

He went on to become an engineer for a leading IT company and now has a successful startup. I just wonder what the other kids could have achieved if they had better encouragement.