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.
On Mon, Apr 29, 2013 at 12:31 PM, Dave Airlie airlied@gmail.com wrote:
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.
No argue there, but it would make sense to have a common set of ioctls for buffer management. The dumb buffer interface is for generic userspace but for non-generic cases there is still a need for something to prevent code duplication for the SoC people.
We could have a "less dumb" interface with support for common stuff like scanout bufs, offscreen bufs, cursor bufs, CMA, overlays, etc, and with room for driver specific flags. There could also be a generic interface for 2d acceleration (solid and copy) and the sync stuff needed for it. For stuff that doesn't fit our interface there is always the possibility to add ioctls. I think the abuse of the dumb buffer interface is an indication that there is a need for something like this.
-Patrik
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.
No argue there, but it would make sense to have a common set of ioctls for buffer management. The dumb buffer interface is for generic userspace but for non-generic cases there is still a need for something to prevent code duplication for the SoC people.
No it means SoC people need to duplicate more code in userspace.
Adding restrictive interfaces to do dumb buffer allocation is never going to end well, someone will always come up with a new buffer type that is slightly different than the previous ones you came up with for their special SoC. The old TTM APIs we had tried to do this generically, and it was too messy. I'm not sure if I can say this plainer: THIS IS NOT A GOOD IDEA AND I WON'T MERGE IT.
You also defeated any hope of me taking you seriously when you suggested adding generic accel interfaces for 2D, because acceleration doesn't belong in the kernel, Lets get this straight, drm isn't fbdev, it isn't an unmaintained free for all fastest hack wins. If I catch this sort of bullshit happening in drm drivers I'll be pulling maintainer plugs out.
Dave.
On Tue, Apr 30, 2013 at 10:19 PM, Dave Airlie airlied@gmail.com wrote:
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.
No argue there, but it would make sense to have a common set of ioctls for buffer management. The dumb buffer interface is for generic userspace but for non-generic cases there is still a need for something to prevent code duplication for the SoC people.
No it means SoC people need to duplicate more code in userspace.
Adding restrictive interfaces to do dumb buffer allocation is never going to end well, someone will always come up with a new buffer type that is slightly different than the previous ones you came up with for their special SoC. The old TTM APIs we had tried to do this generically, and it was too messy. I'm not sure if I can say this plainer: THIS IS NOT A GOOD IDEA AND I WON'T MERGE IT.
I certainly don't have the big picture of this and I trust you in your decision.
My idea was not to have a restrictive interface but to have something thin for the most common parts and allow it to be extended for every use case. But if it didn't work before there is little point in doing the same mistake again. And ofc there is no such thing as a non restrictive generic interface.
You also defeated any hope of me taking you seriously when you suggested adding generic accel interfaces for 2D, because acceleration doesn't belong in the kernel, Lets get this straight, drm isn't fbdev, it isn't an unmaintained free for all fastest hack wins. If I catch this sort of bullshit happening in drm drivers I'll be pulling maintainer plugs out.
Don't worry, there are no such patches coming your way.
Thanks Patrik
dri-devel@lists.freedesktop.org
-
Dave Airlie -
Patrik Jakobsson