On Wed, Apr 6, 2016 at 11:12 AM, Chih-Wei Huang <[email protected]> wrote: > 2016-04-04 6:25 GMT+08:00 Rob Herring <[email protected]>: >> On Sun, Apr 3, 2016 at 12:29 PM, Chih-Wei Huang <[email protected]> >> wrote: >>> Besides, the module name is still gralloc.drm. >>> How about call it gralloc.gbm? >> >> Eventually yes, but for now it is more convenient for my development >> to keep the name the same. >> >>> That means it can coexist with the current >>> gralloc.drm module so the transition to it >>> will be easier. Agree? >> >> It's not binary compatible, only source compatible ATM, so they can't >> really coexist yet. The gralloc implementation specific dependencies > > The co-existence means to put the two gralloc > implementations in the same image and > select which one to be used by GPU at runtime. > This is carried out by our init.sh like > > case "$(cat /proc/fb | head -1)" in > *virtiodrmfb) > set_property ro.hardware.gralloc gbm > set_property ro.hardware.hwcomposer drm > ;; > 0*inteldrmfb|0*radeondrmfb|0*nouveaufb|0*svgadrmfb) > set_property ro.hardware.gralloc drm > set_drm_mode > ;; > ... > esac > > They don't need to be binary or source compatible, I think.
They have to be binary compatible with mesa and hwc as those are dependent on the specific gralloc implementation. > I guess the first supported GPU is virgl. Right? Yes. Any gallium driver really. The classic mesa drivers will need their own additions for GBM map/unmap. > When could we expect it's ready to test? Not sure. Definitely not until the GBM interface is set. There's not really much reason for android-x86 to move to it until it gets flushed out. Rob _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
