I am currently testing your patch set, on amd-staging-drm-next (380d480842d584278dba9aa74341017d8c7d8c23) with an AMD tahiti xt part and a displayport monitor. patch02 drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c did not apply but seems kind of benign. It's working out of the box on my AMD tahiti xt part. I did not manage to break it with aggressive mode programming. Let's see how it goes with my everday usage. > The series adds preliminar SI support as a Proof Of Concept, > based on the idea that DCE6 is similar to DCE8, to be reviewed and refined Did want to do it, but did drop it due to DC code getting fixed with too much changes. Brutally mapping DCE6 to DCE8 is an act of faith... and it's working on my part. > Android-x86 need/motivation lies in the following chain of dependencies: > Vulkan radv requires gbm gralloc prime_fd support, > gbm gralloc requires drm hwcomposer, > drm hwcomposer requires Atomic Display Framework, > Atomic Display Framework requires AMD DC, currently not supporting SI. > > So the goals are: > 1) to get Vulkan radv working on SI parts for android-x86. AFAIK, Vulkan support is not dependent on the display block. I am running heavy vulkan games on a custom gnu/linux x86_64 AMD hardware based system, then the hwcomposer is android only? > 2) to remove the gap in SI (GCN 1st gen) not having atomic support. I was nearly sure that atomic support was implicitely added for parts supporting only legacy DRM mode programming interfaces? -- Sylvain _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
