Raspberry Pi
category: code [glöplog]
Neat! I wonder if there's enough access to write some useful GLES2 extensions (eg. instancing).
Good news delivered by ruairi at 13:37
As far as I know the ARM userland for Videocore simply serializes the api commands and pushes them to the _real_ driver which runs on the VC itself. In other words; what they have opensourced isn't really the GLES driver. :)
Doh. Looking at the source code it appears that's the case. So this is not really that interesting unless you're writing a window manager or something of that nature.
It might have some positive consequences for non-Linux operating systems at least. I'm waiting for Risc OS with great interest - should come out sometime soon.
Raspberry Pi GPU Driver Turns Out To Be Crap
Long version of what has been said above.
Long version of what has been said above.
and this is news? xernobyl? they'd never give you the microcode for the chip. a "product" thing. *yawn* ;)
What harm could come of that?
Firmware would reveal how GPU works -> hordes of patent trolls would descend.
parcelshit I don't think not even the best engineer in the universe would be able to reverse a complete GPU based on microcode, in enough time to make it worth.
That is true but you can guarantee there'd be IP sensitive things revealed in the binary blob.
I know. But those are everywhere, even on open source software.
Anyway, does that opensource thingy allows you to make OpenGL calls without booting to linux? That would be sweet, having bootable demos without OS, using OpenGL.
Anyway, does that opensource thingy allows you to make OpenGL calls without booting to linux? That would be sweet, having bootable demos without OS, using OpenGL.
yumeji: But it's not "microcode"; it's a full OpenGL ES 2.0 stack. What they released was just an RPC-shim in disguise.
My criticism isn't that they were somehow obliged to release the source code of their driver; it's that they claim they did, but in reality did not at all.
xernobyl: it does, indeed. But you need to include 2 megabytes worth of "firmware" (or rather, an OS for the VC) to upload to the VC at boot.
My criticism isn't that they were somehow obliged to release the source code of their driver; it's that they claim they did, but in reality did not at all.
xernobyl: it does, indeed. But you need to include 2 megabytes worth of "firmware" (or rather, an OS for the VC) to upload to the VC at boot.
Code:
GL_APICALL void GL_APIENTRY glVertexAttrib1f (GLuint indx, GLfloat x)
{
glintAttrib(GLXX_API_20, indx, x, 0.0f, 0.0f, 1.0f);
}
GL_APICALL void GL_APIENTRY glVertexAttrib2f (GLuint indx, GLfloat x, GLfloat y)
{
glintAttrib(GLXX_API_20, indx, x, y, 0.0f, 1.0f);
}
GL_APICALL void GL_APIENTRY glVertexAttrib3f (GLuint indx, GLfloat x, GLfloat y, GLfloat z)
{
glintAttrib(GLXX_API_20, indx, x, y, z, 1.0f);
}
GL_APICALL void GL_APIENTRY glVertexAttrib4f (GLuint indx, GLfloat x, GLfloat y, GLfloat z, GLfloat w)
{
glintAttrib(GLXX_API_20, indx, x, y, z, w);
}Interesting. I thought it would be a little more SCALAR when it comes to single values.
RISC OS is out: http://www.raspberrypi.org/archives/2338. Unfortunately, it didn't seem to work with the two sd cards I tried :/
My failed OGL programming talk for codebits 2012 is at http://videos.sapo.pt/eyA6guwIeQ9bBY8JZS0k with source code here http://github.com/xernobyl/codebits2012 in case anyone reading this feels like wasting some minutes.
Nice talk, I have to start using my RPi more as a demo machine and less like a cheap linux server :P
How can I do texture streaming on the RPI?
A small framebuf experiment that does streaming with ES 1.1:
svn://www.kameli.net/marq/koelli
svn://www.kameli.net/marq/koelli
So, I got a Raspberry PI last year, from Maplin, with the Raspbian installed.
Anyway, I didn't have an HDMI screen then and so I tried it once on my TV and then forgot it, because of overscan problem and unresponsiveness.
Now, I remembered and I tried again on proper monitor and decide to try more to get into it. But it's fucking unresponsive. I used to have an Asus EEE PC with Windows XP and thought that was unresponsive. But this one is what really means unresponsive, I can't believe it!
Why they chose such slow Linux to promote the device? Most newbies will be like wtf it's crap, and move away. I mean, the machine is not slow, I was into gamepark and all that OpenHandheld and the Raspberry Pi is around 3x faster compared to my benchmark in Caanoo. And I have seen what you can do with the gameparks already. But the Linux dist is too slow for those machines.
I might try Mint. And even Risc OS for the fun. That last one was running on much slower ARM in the past.
But before that, can you suggest something? Is it slow because of desktop software rendering? (CPU jumps to 100% just be moving some window or even moving the mouse around). Is there GPU solution that I can try? I also tried to do a full update/install (sudo apt-get install something all) but still.
Or maybe it's not meaned to be used from GUI? Ok, linux geeks do it from the command line. But it's misleading for the newbie, that unresponsiveness is worst than crappy netbooks. He also gets a wrong feeling of what the processing power can do.
Anyway, I didn't have an HDMI screen then and so I tried it once on my TV and then forgot it, because of overscan problem and unresponsiveness.
Now, I remembered and I tried again on proper monitor and decide to try more to get into it. But it's fucking unresponsive. I used to have an Asus EEE PC with Windows XP and thought that was unresponsive. But this one is what really means unresponsive, I can't believe it!
Why they chose such slow Linux to promote the device? Most newbies will be like wtf it's crap, and move away. I mean, the machine is not slow, I was into gamepark and all that OpenHandheld and the Raspberry Pi is around 3x faster compared to my benchmark in Caanoo. And I have seen what you can do with the gameparks already. But the Linux dist is too slow for those machines.
I might try Mint. And even Risc OS for the fun. That last one was running on much slower ARM in the past.
But before that, can you suggest something? Is it slow because of desktop software rendering? (CPU jumps to 100% just be moving some window or even moving the mouse around). Is there GPU solution that I can try? I also tried to do a full update/install (sudo apt-get install something all) but still.
Or maybe it's not meaned to be used from GUI? Ok, linux geeks do it from the command line. But it's misleading for the newbie, that unresponsiveness is worst than crappy netbooks. He also gets a wrong feeling of what the processing power can do.
Risc OS works like a charm at least. The SD card problem was caused by an early SD slot that didn't report that a card was inserted. Can be fixed by soldering or otherwise hardwiring the spring-loaded switch on the slot to a closed position. Linux doesn't care, but Risc OS does.
@Optimus: Double the GPU memory in the config.txt file (= to 128 -> gpu_mem=128 ) and the system becomes more responsive in Full HD resolution. A 512mb RPi is needed for that, as 256mb doesn't cut it for anything remotely looking desktop.
Ok, I think I have the 512mb model. Will try that.
Do not expect miracles, however. It's still a 700MHz ARMv6 processor, but the 128mb makes the GUI more responsive and bearable.