On Wednesday 19 March 2008 05:21:43 am Tom Cooksey wrote: > > > 2) Sortof related to the above... it would be very cool to have a very > > > simple drawing API to use on top of the modesetting API. A simple blit > > > & solid fill would surfice. I've always found it odd that the internal > > > kernal API for framebuffer devices includes blit and solid fill, but > > > that API is never exposed to user-space applications - even though it > > > would be _very_ useful. > > > > I don't think this will be done. Main reason is that newer hw is hard to > > program, no 2d anymore so you have to program the whole 3d pipeline stuff > > and we don't want such code in kernel. > > > > So the idea here is to use one userspace driver like gallium3d. Basicly > > you do a winsys for your use and you can also do a new frontend for > > gallium other than a GL frontend or wait for new frontend to appear :) > > Hmm... If you have to use gallium to talk to the hardware, shouldn't fbcon > be renamed to glcon? :-) Also, while 2D is dissappearing on desktop, it's > very much alive on embedded, for the moment at least.
That depends on your definition of "embedded". I think what you're referring to are dummy framebuffers or gpu's that were made with some absolutely silly requirements like "no known bugs" policy which implies that all they have is an underperforming 2D engine. In both of those cases you already lost. So if you're trying to accelerate or design framework based on those than honestly you can just give up and go with an all software framework. If you're referring to actual embedded GPU's the current generation is actually already fully programmable and if you're designing with those in mind than what Jerome said holds. > I can't see fbdev > going anytime soon if the only replacement is a full-blown programmable 3D > driver architecture. Perhaps a new, simple API could be created. On desktop > it would be implemented as a new front-end API for gallium and on embedded > it would be implemented using a thin user-space wrapper to the kernel > module? I don't think that makes a lot of sense. Gallium3D is an interface to hardware - it models the way modern graphics hardware works. Front-end's in the Gallium3D sense are the state-trackers that are used by the API that you're trying to accelerate. So if your hardware is an actual GPU that you can write a Gallium3D driver for, than front-end for it would be just another api (you could be just using GL at this point). > A bit like what DirectFB started life as (before it started trying > to be X). Well, that's what you end up with when you start adding things that you need across devices. I know that in the beginning when you look at the stack you tend to think "this could be a lot smaller!", but then with time you realize that you actually need all of those things but instead of optimizing the parts that were there you went some custom solution and are now stuck with it. All in all I don't think what you're thinking about doing is going to work. You won't be able to accelerate Qt vector graphics framework with the devices that you're thinking about writing all this for so I don't think it's a time well spent. Sure drawLine or drawRectangle will be a lot faster but the number of UIs that can be writen with a combination of those is so ugly and unattractive it's a waste of time. Not even mentioning that it's pointless for companies that actually care about graphics because they're going to have recent embedded GPU's on theis devices. So if you actually care about accelerating "graphics' than you need to think about current generation of embedded chips and those are programmable. z ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
