Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver
I don't think that matters for this driver, its totally not for acceleration, write a real driver if you have some case where copying algorithms are going to matter. It will matter if you want a generic dumb server that can handle stuff like PCI cards as well, but in fact it may well be best if the X server simply does some timings. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver
On Fri, Sep 30, 2011 at 10:12 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: I don't think that matters for this driver, its totally not for acceleration, write a real driver if you have some case where copying algorithms are going to matter. It will matter if you want a generic dumb server that can handle stuff like PCI cards as well, but in fact it may well be best if the X server simply does some timings. probably makes sense to just rename the shadow preferred attribute to dumb_bos_are_cached or something. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver
On Thu, 29 Sep 2011 16:26:32 +0100, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred. I've only added this for intel/radeon which support the dumb ioctls so far. I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor. If you need something really fancy you should be writing a real X.org driver. Would prefer_shadow ever be 0? Isn't preferred_depth just a static (non-driver-specific) preference list like 24, 30, 16, 15, 8 or something? Do we not expose the list of supported depths somewhere else? pgp9la97FKS2h.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver
Would prefer_shadow ever be 0? Yes thats for the USB and vmware type users, where the buffer is just a main RAM buffer not in VRAM or uncached memory. Isn't preferred_depth just a static (non-driver-specific) preference list like 24, 30, 16, 15, 8 or something? Do we not expose the list of supported depths somewhere else? No we don't as we have userspace drivers that know as much as our kernel drivers about the hw, I was tempted to go for a list, but it gets a bit messy to enumerate, and really the generic driver doesn't care, it just wants to pick one value for autoconfiguration, if someone sets a value in xorg.conf and it blows up well thats their issue and they can pick another value. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver
On Thu, 29 Sep 2011 16:26:32 +0100 Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred. I've only added this for intel/radeon which support the dumb ioctls so far. I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor. Actually there is probably one other thing to report - which is whether the buffers are cached. That general piece of info front/back buffer cached/uncached allows you to both make intelligent decisions about using back buffers and also about which copy algorithms to use. I guess X could work it out by timing algorithms at start up. Also you call this max cursor width - in some devices isn't it actually a fixed cursor width ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver
On Thu, 29 Sep 2011 09:43:12 -0700 Eric Anholt e...@anholt.net wrote: On Thu, 29 Sep 2011 16:26:32 +0100, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com For the simple KMS driver case we need some more info about argb cursor limits and a preferred depth and if shadowed framebuffer access is preferred. I've only added this for intel/radeon which support the dumb ioctls so far. I really don't want to expose a truck load of info, just enough for X to start without configuration with a hw cursor. If you need something really fancy you should be writing a real X.org driver. Would prefer_shadow ever be 0? Devices which are fully cache coherent with the CPU are probably a good example. No point running back buffers then. Also any device with a generally slow CPU/GPU interface rather than one where write is fast but read is not. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
