Re: DRM & QWS

[Tom C. <tho...@tr...>]

On Wednesday 26 March 2008 19:32:22 Kristian Høgsberg wrote:
> On Wed, Mar 26, 2008 at 1:50 PM, Tom Cooksey
> <tho...@tr...> 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