Hi Sylvain, On Mon, Oct 8, 2018 at 2:04 PM <sylvain.bertr...@gmail.com> wrote: > > 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.
Thanks for info, do you have some github or patch to share for comparison/mutual knowledge? > > > 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. Do you mean just pretending SI/DCE6 parts were belonging to CIK/DCE8 family? That was a doubt for me, because GCN 2nd Generation additions were: FreeSync support (which should be missing in SI/GCN 1st generation), AMD TrueAudio (not sure about impacts in DC), A revised version of AMD PowerTune technology (less states in GCN 1st gen), GCN 2nd generation introduced an entity called "Shader Engine" While implementing the DCE6 code paths with 'systematic conservative approach' I have started to check how/if extend the approach to dce60/resources and dce60/irq, I'd like to know if to push further in that direction or if keep the DCE8 headers/masks "hack" One problem I see are Mosaic Colored Artifacts on screen surface in the 3D renders of 3Dmark Slingshot Extreeme, another visual problem is some imperfection of video sync/buffer swaps with drm_hwcomposer stack, same as per other GCN families. It will be interesting to launch some conformance tool like Piglit on linux, Android CTS dEQP VK tests, but after having triaged/removed most of the current drm gralloc regressions. Mauro > > > > 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? Yes, at the moment drm_hwcomposer is used only in Android builds > > > 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? drm_hwcomposer API does not see atomic properties with amdgpu on SI parts. if Atomic Display Framework available in amdgpu, then hwc, gbm gralloc and radv would be already working on Android. Also radeondrmfb does not support Atomic Display Framework and that is a problem to have one stack for all drivers, becase with AMD DC, radeon r5xx... r7xx parts will not work even if OpenGLES supported. Mauro > > > -- > Sylvain _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
