On Wednesday 26 March 2008 19:32:22 Kristian Høgsberg wrote: > On Wed, Mar 26, 2008 at 1:50 PM, Tom Cooksey > <[EMAIL PROTECTED]> wrote: > ... > > I guess what I was thinking about was a single API which can be used on > > 3D-less > > (or legacy, if you want) hardware and on modern hardware. If the graphics > > hardware > > is a simple pointer to a main-memory buffer which is scanned out to the > > display, then > > your right, you might as well just use user-space shared memory, as we > > currently do. > > A new API would only be useful for devices with video memory and a > > hardware blitter. > > There are still new devices coming out with this kind of hardware, the > > Marvel PXA3x0 > > and Freescale i.MX27 for example spring to mind. > > I agree with you that it probably doesn't make sense to use > gallium/mesa on everything everywhere. There are still small devices > or early boot scenarios (you mention initramfs) where gallium isn't > appropriate. However, there is no need to put this a 2D engine into > the kernel. What the drm ttm gives us is a nice abstraction for > memory management and command buffer submission, and drm modesetting > builds on this to let the kernel set a graphics mode. And that's all > that we need in the kernel. Building a small userspace library on top > of this to accelerate blits and fills should be pretty easy.
I had a think about this last night. I think Zack is probably right about future graphics hardware. There's always going to be devices with simple graphics, having a framebuffer in main memory and a few registers for configuration. I think in the future, if more advanced graphics are needed, it will take the form of programmable 3D hardware. Take the set-top-box example I gave: While I stand by the fact that a low-power 3D core can't render at 1920×1080, a software-only graphics stack also can't render at this resolution. I'm just thinking about the problems I've been trying to solve getting Qt to perform well on the Neo1973 with it's 480x640 display and 266Mhz CPU. So for simple, linear framebuffer devices we have fbdev. For programmable 3D, we have gallium/DRM. There's still the issue of early boot for 3D devices, but as Jesse mentioned, the DRM drivers can include an fbdev interface as the intel driver does already. Ok, I'm satisfied. Thanks to all. :-) Cheers, Tom ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
