User: Password:
|
|
Subscribe / Log in / New account

Raspberry Pi VideoCore driver code released

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 0:21 UTC (Thu) by airlied (subscriber, #9104)
In reply to: Raspberry Pi VideoCore driver code released by dlang
Parent article: Raspberry Pi VideoCore driver code released

the API to the hw device isn't known, but I can guarantee this isn't it. HW has in the past had an API quite close to GL (even nvidia does it kinda like that now). but the thing is GLES requires a compiler, no one sane puts a compiler in hardware, GLSL isn't at the opcode level, its at the C level. Not opcodes at an assembly language.


(Log in to post comments)

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 0:46 UTC (Thu) by dlang (subscriber, #313) [Link]

The API to a modem is the AT command set

does anyone seriously think that this is what the bare hardware understands? NO. But this is still the API to the peripheral.

Unless there is some other way to interact with this GPU, this is the API for the GPU. You may not like it, or may want to have a lower-level API, but that's not relavent to what the API is.

let's look at storage.

you can have a very, very low-level API (MFM/RLL era)

step this many cylinders in this direction from where you are, wait this long from the 'start of track' marker and start reading/writing data

you can have a low-level API (IDE/ATA/SCSI era)

write this chunk of data to this disk block, potentially with reordering of actions

you can have a medium-level API (filesystems)

you say you want to create a new file and write to it, the filesystem creates directory entries, decides where the file will actually live, etc

If a device plugs into your network and implements the NFS protocol, it doesn't make your OS any less 'open' to use this device, even if you don't have access to the software running on this device, or if said software in in ROM

and you can have a high-level API

object based storage, think web based storage (although people keep talking about having this at the drive level as well), you tell the storage what blob you are dealing with and you read/write the entire blob

note that the way the storage is attached doesn't have that much to do with the API level.

you have experimental drives that you talk object based APIs via a SCSI buss, and you have SCSI level APIs that you talk to over an ethernet bus.

It doesn't matter that most GPU vendors are shipping devices where the API is at the same level as the old MFM/RLL hard drives. Having this GPU operate at a higher level (ATA/SCSI equivalent) may be a dead end, or it may be the wave of the future, people will disagree and only time will tell.

There can be very real advantages to having higher level APIs to devices

But in any case, API for this device really is the high-level interface. you can prove this by talking to it.

> no one sane puts a compiler in hardware

what about ACPI? I thought that handling those calls required a compiler in the BIOS

you may argue that CPI isn't sane, but sanity (expecially by the terms prior to a new thing being released) is a poor indicator for how successful something is going to be.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 0:54 UTC (Thu) by airlied (subscriber, #9104) [Link]

there is an ACPI interpreter in the BIOS, its not a compiler, it doesn't take highlevel C like language and compile it down to basic assembler opcodes, ACPI langugage is like assembly, GLSL is exactly like C.

But anyways I'm not sure why you think I care about your opinion, you've made up your mind that you want to live with what you are given by vendors, I'm more interested in what vendors can do to help Linux than themselves.

Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 1:18 UTC (Thu) by dlang (subscriber, #313) [Link]

> Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.

not the greatest open-sourcing ever no :-)

but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU.

I don't see this as being significantly different from an Open Source tool that makes calls to Google Maps.

If it's running on a separate CPU, and it's not doing things like sharing memory, then it doesn't count as far as the Openness of the first software.

As others have noted, if you keep drilling down, you get to things like the microcode on the x86 CPU as something that's not open, and that you are accessing through a much higher level API from what the native chip supports. The x86 CPUs can even include compilers to convert the x86 instruction set to lower level code.

Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU?

Does it make Linux any less free if it's running on vmware emulating a x86 CPU instead of on native hardware?

what about running Linux on an ARM emulator running on Windows instead of on a real ARM chip?

at what point does the manipulation of the commands before they hit the actual circuit mean that the API for those commands is not 'legitimate'?

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 13:23 UTC (Thu) by pboddie (guest, #50784) [Link]

but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU.

I think the objections people have to this announcement are mostly centred on the assertion that Broadcom have opened up access to the underlying technology when in practical terms all they have really done is acknowledged the nature of the API for specific functionality provided by the SoC. And all of this publicity downplays the fact that they've moved software behind the curtain and onto the proprietary CPU core.

So although this release helps people to write software against that narrow API, it's very much business as usual.

Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU?

Although you can have CPUs with loadable microcode, I don't think these arguments really help the discussion along because they inevitably lead to remarks like "You can't fabricate your own CPUs, and I suppose you extremists won't be happy until the proletariat have seized control over the means of production!"

Far more illustrative is to consider things like printers supporting standard interfaces like PostScript. It's a positive thing that you can (or could) get a printer that any system could talk to using a well-defined (and hopefully standard) communications mechanism, but it's a different matter from being able to enhance the printer's own operation, if this is desirable.

And it's always necessary to question the redefinition of system boundaries because you can easily end up with a dumb terminal talking to a proprietary mainframe that does all your graphics and printing for you. Or you have all your applications running in a proprietary cloud. And so on.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 20:26 UTC (Thu) by dlang (subscriber, #313) [Link]

did they move functionality, or has their chip always worked this way?

pushing functionality away from the main CPU and providing higher level abstractions and APIs is an ongoing process that has been going on as long as computers have been around.

The assertion is that everything running on the ARM processor is now open.

They have said for a while that the source for this userspace code was not going to be particularly interesting to people, but there was still a loud demand for this code to be opened. They did so and now people are complaining that it's not interesting.

no matter what you believe the boundary of openess should be, there is no doubt that this is a move in the right direction.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 22:07 UTC (Thu) by pboddie (guest, #50784) [Link]

It's actually not correct to bundle things like abstraction together with where functionality has migrated to over the years, mostly because functionality has migrated in different directions, whereas the level of abstraction in the components of the average system has mostly increased.

For example, video control was indeed done by the CPU in various microcomputers and then migrated to dedicated circuits of different forms and with increased sophistication, but other activities - notoriously, modems and printers - have seen the CPU bear the bulk of the workload in various periods. Much of this depends on whether it is considered worthwhile to have dedicated hardware for a particular task that could be done in software running on general purpose hardware.

I agree that for practical purposes being able to build these "drivers" from source increases the general level of support for the SoC in Free Software projects and is thus an improvement on the previous situation, but given the limitations on actually modifying the system's behaviour (the objections brought up by various driver developers), it's clearly not the milestone that we've been sold by the announcement.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 23:23 UTC (Thu) by ncm (subscriber, #165) [Link]

It depends on whether the second CPU has access to the RAM and devices of the first, no?

Raspberry Pi VideoCore driver code released

Posted Oct 26, 2012 9:37 UTC (Fri) by renox (subscriber, #23785) [Link]

>It depends on whether the second CPU has access to the RAM and devices of the first, no?

As if there wasn't other devices with drivers in the Linux kernel which has closed source firmware and which can corrupt your RAM with DMA.
If memory serves, the IO-MMU which can protect you from buggy devices is(was?) often deactivated because it didn't work correctly..

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 1:23 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

> what about ACPI? I thought that handling those calls required a compiler in the BIOS

No, ACPI code is never executed by the BIOS.

Sane companies and compilers in hardware

Posted Oct 26, 2012 0:11 UTC (Fri) by ncm (subscriber, #165) [Link]

"no one sane puts a compiler in hardware"

Funny that you should say this... Every 686+ chip produced by Intel and AMD today has a compiler in hardware. It takes for its input x86 instructions, compiles them to RISC operations, and peephole-optimizes the hell out of that. It is very unlikely that the shader compiler in this gadget is within one order of magnitude as complex as what is in every i5. Maybe not even two.

I don't know if those x86->RISC compilers are in rewritable microcode, but that's the way I would bet. That compiler's output has total access to all memory and devices. It might even run when you install new microcode, and doctor that, Ken Thompson-style, to have the same back door as the old.

There are probably good reasons for China to have their own, independent CPU designs, even at a cost of reduced performance. And for the rest of us, too, maybe.

Shader compiler on the GPU

Posted Oct 26, 2012 14:43 UTC (Fri) by alex (subscriber, #1355) [Link]

I don't think that was done for this particular release. As far as I can tell it's a design feature of this family of GPUs. So all platforms using the chip will use the same RPC like API to the GPU.

Raspberry Pi VideoCore driver code released

Posted Oct 26, 2012 18:30 UTC (Fri) by dlang (subscriber, #313) [Link]

> the API to the hw device isn't known, but I can guarantee this isn't it.

If that's the case, please point to the code that talks the "real" API

It's not in the kernel, it's not in userspace, so where is it?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds