On Wed, Apr 3, 2019 at 7:58 PM David Airlie <airlied@xxxxxxxxxx> wrote:
On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
>
> Time to kill some bad sample code people are copying from ;)
>
> This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> function is pretty much the only function which is carried over largely
> unmodified. Everything else is upside down.
>
> It is a single monster patch. But given that it does some pretty
> fundamental changes to the drivers workflow and also reduces the code
> size by roughly 70% I think it'll still be alot easier to review than a
> longish baby-step patch series.
>
> Changes summary:
> - Given the small amout of video memory (4 MB) the cirrus device has
> the rewritten driver doesn't try to manage buffers there. Instead
> it will blit (memcpy) the active framebuffer to video memory.
Does it get any slower, with TTM I just wrote it to migrate just the
frontbuffer in/out of VRAM on modeset, won't we end up with more
copies now?
> - All gem objects are stored in main memory and are manged using the
> new shmem helpers. ttm is out.
> - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
> that too by default. There was a module parameter which enables 24/32
> bpp support and disables higher resolutions (due to cirrus hardware
> constrains). That parameter wasn't reimplemented.
This might be the big sticking point, this is a userspace regression
for a feature that was explicitly added a few years ago, can we really
get away without it?
Chrome OS testing in VMs was one of the consumers of 32bpp on cirrus, and we have gotten rid of cirrus in favor of virtio gpu, so we'd be fine. Of course I can't speak for other consumers :)
Stéphane
The rest looks good though!
Dave.
> - The simple display pipeline is used.
> - The generic fbdev emulation is used.
> - It's a atomic driver now.
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
