Hi Dave!
I guess I should have opened a discussion around armsoc a lot earlier than now as you clearly have some frustrations! Sorry about that.
It also sounds like you have some ideas over how we should approach the technical side and those I really want to understand.
-----Original Message----- From: Dave Airlie [mailto:airlied@gmail.com] Sent: 23 April 2013 21:29 To: Tom Cooksey Cc: dri-devel; Inki Dae Subject: Re: abuse of dumb ioctls in exynos
Having a flag to indicate a dumb buffer allocation is to be used as a scan-out buffer would be useful for xf86-video-armsoc. We're trying to keep that driver as generic as possible and currently the main device- specific bits are what flags to pass to DRM_IOCTL_MODE_CREATE_DUMB for scanout & non-scanout buffer allocations. If a generic scanout flag could be added, it would simplify armsoc a fair bit and also allow the DRM drivers we're using armsoc with to comply with the don't pass device- specific flags to create dumb.
For reference, the device-specific bits of armsoc are currently abstracted here:
Note: We are still using DRM_IOCTL_MODE_CREATE_DUMB to allocate pixmap and DRI2 buffers and have not come across any issues with doing that. Certainly both Mali-400 & Mali-T6xx render to linear RGBA buffers and the display controller's in SoCs shipping Mali also seem to happily scan-out linear RGB buffers. Getting armsoc to run on OMAP (again) might need a device-specific allocation function to allocate the tiled format used on OMAP, but only for efficient 90-degree rotations (if I understood Rob correctly). So maybe we could also one day add a "this buffer will be rotated 90 degrees" flag?
What part of don't use dumb buffer for acceleration is hard to understand?
Christ I called them DUMB. Lets try this again.
DON'T USE DUMB BUFFERS FOR ALLOCATING BUFFERS USED FOR ACCELERATION.
Right, I _think_ I understand your opinion on that. :-)
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:
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.
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.
Another option we nearly went with is to use ION to allocate all buffers, using the PRIME ioctls to import those buffers we want to scanout into the display controller's DRM driver. ION's a pretty good fit, but requires some SoC-specific logic in userspace to figure out E.g. the display controller doesn't have an IOMMU and 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.
Now that we've cleared that up, armsoc is a big bag of shit, I've spent a few hours on it in the last few weeks trying to get anything to run on my chromebook and really armsoc needs to be put out of its misery.
This is why we need a bug tracker! To objectively quantify "big bag of shit" and fix it. :-)
The only working long term strategy for ARM I see is to abstract the common modesetting code into a new library,
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.
and write a per-GPU driver.
So in our bit of the ARM ecosystem, the GPU is just the bit which draws 3D graphics. The 2D drawing hardware is separate, as is the display controller as is the video codec. This is reflected in the driver model: The GPU driver is totally bespoke, the display controller interface is DRM/KMS and the video codec is v4l2. There doesn't appear to be a standard kernel interface for 2D draw operations, so these seem to be added to DRM. We now have dma_buf which lets us share buffers between those different drivers.
So by per-GPU driver, I assume you mean per-display-controller driver, for which KMS is already a great abstraction.
What you are doing now is madness and needs to stop.
Or at least change direction - once we've figured out a new one.
Cheers,
Tom