Which doesn't mean that it cannot or will not change.
Why no drivers for Powervr SGX
- Thread starter Dawgmatix
- Start date
Which doesn't mean that it cannot or will not change.
I can't think of a single piece of silicon IP where the original vendor is responsible for the distribution of drivers. Each chip and, even more, each system/handset has sufficient differences that it's completely not practical to do so. This is especially so for kernel level drivers. Addresses can be different, memory access policies can be different, one core may have some bug fixes that the other one doesn't, in the IP itself or in the logic that surrounds it. Etc.
And no system provider is going to allow third party to release a kernel mode driver without extensive local testing.
If even in the highly standardized regular notebook space, official GPU drivers don't support those of a notebook, it's just not going to happen for the embedded market.
Are these drivers linux desktop integration (i.e. integrated with X, the window manager, cairo, etc.) or are they simply 'your single embedded app can take over the entire screen and go to town'?
Note sure how accurate this document is but according to:-
http://jkridner.s3.amazonaws.com/esc/ESC-341_Dompe.pdf
"Texas Instruments plans to provide open source Linux kernel drivers for the SGX along with binary only libraries toward the end of 2008 that can be used with BeagleBoard."
Well, what I've seen so far is that when an IP provider offers "opengles drivers for linux" what they really mean are a library that is appropriate to have a single standalone application take control of the graphics hardware and command it through OpenGL-ES and not desktop integration/acceleration. No X, Cairo, OpenVG, etc. support. Just a raw, raw driver.
Of course, when you think about it, while the embedded IP may be relatively standard, the LCD/display controller hardware is almost always homegrown or comes from one of a bundle of providers. Then there's the video accelerator to factor in (which likely isn't from the same IP provider) and there's a whole passle of work to do to integrate everything together in terms of framebuffer organization and data structures.
But probably the real reason there aren't any "drivers" (i.e. like we have on our PCs) for the SGX (or other vendors) is because only recently (with the advent of the iPhone) has ARM and the rest of the SOC vendors gotten serious (with their Ubuntu mobile/netbook initiative) about having an accelerated portable desktop. Previously, the use case was more of a set top box, where a single user driver that controlled the entire screen was completely adequate.
Of course, when you think about it, while the embedded IP may be relatively standard, the LCD/display controller hardware is almost always homegrown or comes from one of a bundle of providers. Then there's the video accelerator to factor in (which likely isn't from the same IP provider) and there's a whole passle of work to do to integrate everything together in terms of framebuffer organization and data structures.
But probably the real reason there aren't any "drivers" (i.e. like we have on our PCs) for the SGX (or other vendors) is because only recently (with the advent of the iPhone) has ARM and the rest of the SOC vendors gotten serious (with their Ubuntu mobile/netbook initiative) about having an accelerated portable desktop. Previously, the use case was more of a set top box, where a single user driver that controlled the entire screen was completely adequate.
I can't say what will be in the official release, all I know is that I have seen support for X, framebuffer, ES 1.1 & 2.0 and OpenVG. As you wrote, Linux is being taken more seriously these days
Originally Posted by RussSchultz
Are these drivers linux desktop integration (i.e. integrated with X, the window manager, cairo, etc.) or are they simply 'your single embedded app can take over the entire screen and go to town'?
Reaing your query, has anyone seen Cairo integrated Opengl ES ? Other than Clutter, I havent seen any higher level API using Opengl ES for anything related to window management.
Are these drivers linux desktop integration (i.e. integrated with X, the window manager, cairo, etc.) or are they simply 'your single embedded app can take over the entire screen and go to town'?
Reaing your query, has anyone seen Cairo integrated Opengl ES ? Other than Clutter, I havent seen any higher level API using Opengl ES for anything related to window management.
Cairo is, I believe, what GTK uses as its drawing toolkit, and that's all done and composited on top of X.
Both of those need to be taught to play nice with the open GL/3d hardware and all 3 of those need to be taught to play nice with the LCD controller/output driver.
And that stuff generally isn't 'with it' for embedded linux.
Both of those need to be taught to play nice with the open GL/3d hardware and all 3 of those need to be taught to play nice with the LCD controller/output driver.
And that stuff generally isn't 'with it' for embedded linux.
> Powervr Kernel Drivers Avaliable Now see http://www.gp32x.com/board/index.php?showtopic=45664
I should have mentioned "drawing". In any case, does anyone know of Cairo working with openglES ?
Somehow I don't see that as accelerating drawing at all, and it doesn't solve the problem of actually integrating the hardware into the window manager and display stuff.
The problem is how to pass buffers around so that the OGL hardware, Cairo SW, the window compositor, and the display hardware all understand the buffers.
This stuff has not been provided by the IP vendors to licensees, and it isn't a trivial solution to make a OGL stack (particularly since the vendor supplied stacks are set up this way) to be multi-thread/process aware, allow rendering to separate contexts, etc. etc.
At least one vendor's embedded graphics team has never done a full-up Linux driver, so they point to the desktop team who has, who says "we don't know anything about that hardware".
The problem is how to pass buffers around so that the OGL hardware, Cairo SW, the window compositor, and the display hardware all understand the buffers.
This stuff has not been provided by the IP vendors to licensees, and it isn't a trivial solution to make a OGL stack (particularly since the vendor supplied stacks are set up this way) to be multi-thread/process aware, allow rendering to separate contexts, etc. etc.
At least one vendor's embedded graphics team has never done a full-up Linux driver, so they point to the desktop team who has, who says "we don't know anything about that hardware".
If that one vendor is Imagination then why dont they take the linux kernel devs up on their offer to write free drivers ?
For more details heres a link:
http://www.kroah.com/log/linux/free_drivers.html
For more details heres a link:
http://www.kroah.com/log/linux/free_drivers.html
Thats just 2D texturing. I was talking about using the ES hardware for doing what Compiz does with the full opengl, on a window basis.
This is likely to give the situation an almighty kick in the ass ...
http://tech.slashdot.org/article.pl?sid=09/01/31/1859200
As for not open sourcing because they are afraid of giving out secret sauce, they can always have two sets of drivers like ATI and let the linux developers come up with their own non-secret sauce.
http://tech.slashdot.org/article.pl?sid=09/01/31/1859200
As for not open sourcing because they are afraid of giving out secret sauce, they can always have two sets of drivers like ATI and let the linux developers come up with their own non-secret sauce.
Similar threads
- Locked
