> The reason we (currently) use the dumb buffer interface is because it > does pretty much exactly what we need it to, as we only want linear > RGB buffers:
Except in the cases where it doesn't do what you want, and possibly in the future where it does less of what you want. You've started on a slippery slope, and I'm stopping you before you make things worse. You are going to have to get SoC kernel drivers to add an ioctl that you can use, if you insist on trying to mangle all the different code paths into a single userspace driver, then you are going to take a lot of pain. Its the old helper library vs midlayer, you are inventing a DDX midlayer when you should be inventing a DDX helper library. > On Mali & probably other tiled-based GPUs, the back buffer only gets > written once per frame, when the GPU writes its on-die tile buffer to > system memory. As such, we don't need the complicated memory layouts > immediate mode renders do to improve cache efficiency, etc. On one 3D core, the problem is the driver seems to be wanted to be used across at least omap and exynos, and I assume others will happen as time progresses. > What's more, the 2D hardware typically found on SoCs we're targeting > isn't advanced enough to implement all of the EXA operations and > frequently falls back to software rendering, which only works with > linear RGB buffers. Don't worry about implementing all of EXA, you really probably only want fill/copy for what you are doing. > we must therefore allocate from a contiguous ION heap. By allocating > via the DUMB interface and specifying a scanout hint, we can leave > that decision to the DRM driver and keep userspace entirely generic. > The other reason to go with DUMB rather than ION was because ION > wasn't upstream. Just ask the drm driver directly, no dumb ioctl, no ion. Not sure what the problem is. > Would you mind elaborating a little on this? I assume you're not talking > about libkms? What operations would be performed by this driver which > would need to be abstracted in userspace which aren't already nicely > abstracted by KMS? Once we have a new library of some description, I > assume you're suggesting we modify armsoc to use it? That seems a good > idea as it also means we can use that to implement the HWComposer HAL > on Android and thus use the same driver code can be used with minimal > changes on X11, Android, Wayland, Mir and whatever other new window > system comes along. That's really the point I'm trying to get to. No not libkms, nothing like it. More as Rob said the drmmode code is probably the truly common code, and just write a DDX per SoC. Really anything else you do is going to lull people into a false sense of how much work there is. Distros want to ship a distro that can support all ARM boards at once, they don't want have 15 armsoc builds with different configure flags. Stop and think about how Linux distro downstream might use this. Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
