On Wed, Apr 24, 2013 at 5:58 AM, Tom Cooksey <tom.cooksey@xxxxxxx> wrote: > 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@xxxxxxxxx] >> 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. well, libkms could give you the buffer allocation part. But there is probably room for some library/helper code in xserver to act as the glue between xorg's modesetting related data structures and kms.. ie. basically what is in drmmode_display.c.. libkms isn't really the right place for this as it doesn't have any xserver dependency. I'm not really sure that re-using the same thing for modesetting on android/wayland/etc really makes too much sense, since they wouldn't be using xserver/xrandr and really drmmode_display is all about adapting between xserver/xrandr and kms. Anyways, wayland already uses kms directly, so nothing really used there. And really, tbh, if android was sane it would do the same as wayland. BR, -R > >> 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 > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
