Eric Anholt Leaves Intel's Linux Graphics Team For Broadcom

[brent]

Thats the current state but in the future it can come fast to the oposite:

FEDORA:

http://fedoraproject.org/en/get-fedora#arm

what do we have here, 7 OFFICIAL spins for the general arm standard (armhf or arm7) and 1 UN-official Remix.

DEBIAN:

http://cdimage.debian.org/debian-cd/7.5.0/armhf/iso-cd/

same here, 4-5 spins only unofficial versions of raspbian are there.

Not sure what you're getting at, there is too much babbling your post. In any case, there is no lack of good ARM Linux distributions.

ARM doesn't have standardized hardware platforms and/or system firmware APIs. Every vendor has a ton of custom IP in their hardware, and this may be considered a problem by some. This is why very platform-specific support is required, and it is unlikely to change in the near future.

[blackiwid]

Not sure what you're getting at, there is too much babbling your post. In any case, there is no lack of good ARM Linux distributions.

ARM doesn't have standardized hardware platforms and/or system firmware APIs. Every vendor has a ton of custom IP in their hardware, and this may be considered a problem by some. This is why very platform-specific support is required, and it is unlikely to change in the near future.

And thats one of the main reasons I will buy most likely soon a intel x86 cpu and more important gpu tablet.

Even as example the new lenovo 10" arm pad 10 hd+ has a nice price + nice akku time, and the cpu / gpu power would be enough, its just not usable in 2 years there will be not one normal linux running on it, even with a driver blob.


I would be glad if arm companies would hire people to write free drivers for their socs, but only if it makes any sense.

Maybe I am missinformed but the rPi gpu was not critisised becuase there is no good driver or no good spec but that its hardware-design is so that u cant get very lowlevel u more or less have to send opengl messages to the firmware as driver-interface.

So no matter how much driver experience u have u cant write a normal good driver for it.

k googled abou the driver/hardware again:

So ok its a firmware like with radeon but with 99% of all functionality in it instead of the driver like amd does it.

So ok if they really would remove 99% of the code in the firmware and put it into the driver go for it. So it would be possible to get a somewhat good solution, still the problem with not having a full armv7 sock is a problem.

But they cant do that, else they woul dhave to rewrite any other driver too. like the one for android... I am pretty shure that they dont want to do that. But hey we will see.

[robclark]

Maybe I am missinformed but the rPi gpu was not critisised becuase there is no good driver or no good spec but that its hardware-design is so that u cant get very lowlevel u more or less have to send opengl messages to the firmware as driver-interface.

That is the design of bcom's original closed src driver. But the ARM can drive the GPU just as well. I expect that Eric will be working on an ARM side driver. Not using the whole message-passing-to-coprocessor nonsense.

I really doubt Eric would leave Intel to work on something as mundane as serializing GL calls into IPC messages to a coprocessor.

[smitty3268]

That is the design of bcom's original closed src driver. But the ARM can drive the GPU just as well. I expect that Eric will be working on an ARM side driver. Not using the whole message-passing-to-coprocessor nonsense.

I really doubt Eric would leave Intel to work on something as mundane as serializing GL calls into IPC messages to a coprocessor.

His blog says as much:

There are a lot of open questions still as to how we'll manage the transition from having most of the graphics hardware communication managed by the VPU to having it run on the ARM (since the VPU code is a firmware blob currently, we have to be careful to figure out when it will stomp on various bits of hardware as I incrementally take over things that used to be its job).

I'm kind of doubting he'll use Gallium, though. I don't think i've ever heard him say anything especially nice about Gallium, such as wishing he could use it, and i suspect he'll go with what he's more familiar with, which is a classic driver. It sounds like he wants a lot of custom control, as well, and may think Gallium will get in the way of that.

[asdfblah]

Isn't the graphics stack of the RPi already open source? What about other Broadcom SoCs?

[blackiwid]

Isn't the graphics stack of the RPi already open source? What about other Broadcom SoCs?

it?s strange, technicaly it is kind of.

IN theory they would be kind of comparable to ati, becuase they also depend on loading a driver firmware blob at boot which is not opensource. If you ask richard stallman thats no full free driver. I dont know if you could enforce that with the gpl and a law suit, I am no laywer and I dont know every single word of the gpl out of my mind.


But here its even worse at the moment in 2 ways:

1. the rpi just dont boot with that propriatary blob (thats what I read at least), so u need a propriatary blob to even get it running.

good u could argue that most mainboards dont boot without the installed propriatary bios too, but rms and I guess the gpl togles that microcode as hardware becuase u dont have to change it and u dont have to load a propriatary blob at each boot time from the kernel or grub or something.

2. another problem is that 99% of all features is in the firmware and the user-space driver is just a small wrapper around it, where u can fix nothing or do nothing with it.


The last point at least makes even hyper-pragmatical opensource people that hate the idea or term free software to not accept that as a real opensource driver.

And 1. they will not integrate it into the kernel and 2. no distro will support it officialy.

[tarceri]

How so? If there indeed is dev poaching between mesa-contributing companies, that affects morale and creates an unhealthy environment. I don't see how it's a good sign for the future.

Well for starters more companies hiring Mesa dev's shows the health of the project and represents more financial backing, this is generally always a good thing. I totally disagree that this creates low morale or an unhealthy environment. As a developer my morale would be boosted knowing that there are more job opportunities around, that I could get a pay raise if my current company wasn't going to give me one, or that in fact they might give me one to keep me. Also the comfort in knowing that if intel were to cut back on Mesa development that there are other companies that I could go work for is great peace of mind.

As far as poaching goes its a good thing to allow developers to be paid what they are worth. Not allowing poaching is an antitrust issue which google, apple, ebay, etc are all in trouble over currently.

[blackiwid]

So ok that sounds then at least somewhat ok. So rpi could become in the long run a real open thing. not so pseudo-open. that technicaly maybe meat the requirements of a lisense but does not fullfill the idea behind it.

its a bit like tivoisation, yes it was compatible to the gpl v2 the latest version when this hardware came out. But it did undermine the ideas behind the gpl (at least what the author meant with it).

Another non-ethical, practical question, did I understand it wrong that this firmware design made it possible to have somewhat descent performance with that bad cpu part. Could such driver than not use more cpuload, and make the very slow soc even slower?


So the real question then is, I think I am right if the cpu runs then a full driver and not the gpu-controller like today, it would cost some cpu-time.

So there would be a easy solution with 3 advantages:

The solution would be just release the sourcecode of the firmware.

Advantages:

- no performace issues with the cpu
- its done now.
- u dont need to pay the salary to that opensource developer.

[caligula]

Is the rPi good enough for some tasks, maybe yes, will it get much better no. Yes of course they get maybe then 30fps in glxgears instead of 5, 2d performace is then maybe 10% faster in X or whatever shure. But u have to wait some months have to fiddle around with downloading fresh images from some bogus sites, invest some time, and in the end u are already near the top... while with a 2core 1.4ghz soc with 2gb ram u have 200-500% mehr speed in some cases. Without touching even one line of code. for 20,- Euro more... one less sd-card could have saved u the cost.

I'm not sure if I understood what you were trying to say here but..

RPi is 700 MHz single-core ARMv6 / 512MB / $35 and
Odroid U3 was 1400 MHz quad-core ARMv7 / 2048MB / $59.

If you consider all the stuff you need to set up a system and shipping costs, the $24 price difference is quite tiny.

The differences are huge. If you want computing power, USB powered ethernet is ridiculously slow compared to inter-CPU bandwidth of multi-cores. Odroid cores perform 2x as much cycles in same time, 4x as much cores, at least 2x faster IPC and caches are like 3 orders of magnitude bigger. It can easily be 20 times faster. The CPU on RPi is a joke. The GPU is "ok" for many tasks. After all it decodes H.264 High Profile. But the CPU is a piece of junk. RPi also has USB issues, you need to add a capacitor so it won't boot the CPU if you disconnect/connect USB devices. It also may corrupt SD cards when you write. That's the price you pay when paying $65 instead of $89 for an ARM computer.

However, if you think of computer hardware, they tend to upgrade them every now and then. Well the sad thing is, new RPi is still the same old RPi. No evolution at all. Even the so-dimm version of RPi is the same. Same of shit. Terribly slow. At the same time e.g. some other GPUs got over 100% faster. Accodring to Moore's law evolution happens all the time in chip industry. RPi is stuck in the past. Its only advantage is the price. Even Intels are becoming cheaper and since Intel supports open source, maybe we'll forget about hostile ARM completely when Intel offers similar SoC boards.

[robclark]

So ok that sounds then at least somewhat ok. So rpi could become in the long run a real open thing. not so pseudo-open. that technicaly maybe meat the requirements of a lisense but does not fullfill the idea behind it.

its a bit like tivoisation, yes it was compatible to the gpl v2 the latest version when this hardware came out. But it did undermine the ideas behind the gpl (at least what the author meant with it).

Another non-ethical, practical question, did I understand it wrong that this firmware design made it possible to have somewhat descent performance with that bad cpu part. Could such driver than not use more cpuload, and make the very slow soc even slower?

When I looked at the gpu docs that broadcom release a while back, when they first release the *real* driver code (as opposed to the shim that was released originally), it looked like it did not really depend on the firmware for performance. It is either the firmware or the ARM pointing the gpu block at a command-list. The hardware iterates through the commandlist, rather than needing the videocore to hold it's hand.

Possibly some things benefit from the original do-everything-on-firmware approach, but that approach also did cause it's share of performance problems. I don't really expect a CPU-side driver to be worse overall.

So the real question then is, I think I am right if the cpu runs then a full driver and not the gpu-controller like today, it would cost some cpu-time.

So there would be a easy solution with 3 advantages:

The solution would be just release the sourcecode of the firmware.

Advantages:

- no performace issues with the cpu
- its done now.
- u dont need to pay the salary to that opensource developer.

Long term, I doubt you'll see a lot of FOSS graphics driver devs wanting to work on the original bcom codebase. From a maintainence standpoint, the code sharing with other mesa drivers (especially for a gallium driver) is too big of an advantage to ignore. Not to mention that, from what Eric said on his blog post, the bcom engineers seemed to be more in favor of throwing away the existing code.