[RFC] drm/amd/display: add SI support to AMD DC
Deucher, Alexander
Alexander.Deucher at amd.com
Mon Oct 8 15:47:37 UTC 2018
It's trivial to add the metadata/version headers to the existing firmware, so that is not an issue. The issue is with the firmware itself. If we used the existing firmware, we'd have to add a bunch of really ugly hacks in the driver to work around the current limitations.
Alex
________________________________
From: amd-gfx <amd-gfx-bounces at lists.freedesktop.org> on behalf of Mike Lothian <mike at fireburn.co.uk>
Sent: Monday, October 8, 2018 8:16:01 AM
To: Koenig, Christian
Cc: Mauro Rossi; Wentland, Harry; amd-gfx at lists.freedesktop.org
Subject: Re: [RFC] drm/amd/display: add SI support to AMD DC
I thought it just required the existing firmware, with padding / extra info put around it?
On Mon, 8 Oct 2018 at 12:29 Christian König <ckoenig.leichtzumerken at gmail.com<mailto:ckoenig.leichtzumerken at gmail.com>> wrote:
UVD/VCE on SI with amdgpu would need new firmware.
And so far we never had time to actually look into releasing that firmware.
Regards,
Christian.
Am 08.10.2018 um 13:22 schrieb Mauro Rossi:
Hi Mike,
On Mon, Oct 8, 2018 at 1:00 PM Mike Lothian <mike at fireburn.co.uk<mailto:mike at fireburn.co.uk>> wrote:
Hi Mauro
Do you know if there are any plans to add in UVD support on SI too?
Thanks
Mike
At the moment my focus is on getting a conformant, working and stable
implementation of Atomic Display Framework, with the objective to have it
upstreamed to amd-gfx branch, then staging (drm-next) and maybe merged in linux kernel.
To be honest my attempt is based on code paths inspection and mimicking,
so in this moment I do not even know the state of UVD and what changes are needed,
but, based on what I saw for DCE6 support addition on top of DCE8,
covering all compatible HW modules makes a lot of sense and it is an opportunity to exploit,
if feasible.
For this to happen in most complete and reliable way the feedback of staff who worked on DAL/DC
will be essential, because what I did now was to adapt code for DCE8 to work for DCE6,
but it was like an "optimistic monkey with a keyboard" approach, with all due respect for monkeys with keyboards,
:-) I may have missed dozen of changes.
Mauro
On Mon, 8 Oct 2018 at 03:24 Mauro Rossi <issor.oruam at gmail.com<mailto:issor.oruam at gmail.com>> wrote:
[PATCH 01/10] drm/amd/display: add asics info for SI parts
[PATCH 02/10] drm/amd/display: dc/dce: add DCE6 support
[PATCH 03/10] drm/amd/display: dc/core: add DCE6 support
[PATCH 04/10] drm/amd/display: dc/bios: add support for DCE6
[PATCH 05/10] drm/amd/display: dc/gpio: add support for DCE6
[PATCH 06/10] drm/amd/display: dc/i2caux: add support for DCE6
[PATCH 07/10] drm/amd/display: dc/irq: add support for DCE6
[PATCH 08/10] drm/amd/display: amdgpu_dm: add SI support
[PATCH 09/10] drm/amdgpu: enable DC support for SI parts
[PATCH 10/10] drm/amd/display: enable SI support in the Kconfig
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
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.
2) to remove the gap in SI (GCN 1st gen) not having atomic support.
DCE6 specific code was implemented as a replica of existing DCE8 support
and based on how DCE8 specific code was added on top of DCE10,11 support
by adding dce60* sources, functions, macros for each existing in dce80*
CONFIG_DRM_AMD_DC_SI parameter has been added to control SI support in DC
During this first iteration of review, there are aspects to verify:
- dce60 code has been added mechanically, so there may be redundancies
and space for refactoring part of the code
- dce60_resources was having too many building errors due to missing DCE6 macros
in order to temporarily overcome the problem dce_8_0_{d,sh_mask}.h headers
were used for the PoC
- dc/irq suffered the same problem dce_8_0_{d,sh_mask}.h headers
were used for the PoC
- gfx6 may require some ad hoc initialization, skipped for the moment
- Hainan specific code requires review, as some documentation and code paths
seem to point that famility may not have DCE6, please confirm
- video decoding blocks code have not been touched
- dc/dce/dce_clock_source.{c,h} may be missing some SI/DCE6 specifics
- dc/dce/dce_dmcu.{c,h} may be missing some SI/DCE6 specifics
- dc/dce/dce_hwseq.h may be missing some SI/DCE6 specifics
- dc/dce/dce_link_encoder.h may be missing some SI/DCE6 specifics
- dc/dce/dce_stream_encoder.h may be missing some SI/DCE6 specifics
- dc/amdgpu_dm/* changes may be incomplete
- Any other omissis to be reviewed
- Feedback on best testing strategy required
Review from an expert of the DC impacted modules is recommended
SW Layer
/===============================================================\
| DC Display Timing Mode Asic |
| Interface Service Service Manager Capability* |
| |
| Display Topology Display Link Adapter |
| Path Manager Capability Service Service |
| Service |
|---------------------------------------------------------------|
| GPIO* IRQ I2cAux HW BIOS |
| Service** Manager* Sequencer* Parser* |
| |
| Connector Encoder Audio GPU Controller |
| |
\===============================================================/
HW Layer
Legend:
*dce60 support was added cleanly with dce_6_0_{d,sh_mask}.h headers
**dce60 support was added using dce_8_0_{d,sh_mask}.h headers
Android-x86 preliminary tests results:
[Boots with drm gralloc]
3DMark Slingshot
GFXbench OpenGLES benchmarks OK
V1 GPU benchmark (OpenGLES) OK
Regression in Google Chrome, Youtube (app does not show up)
Regression in Olympus Rising, Chicken Invaders (app does not show up)
[Boots with drm hwcomposer + gbm gralloc]
Google Chrome, Youtube are OK
Vulkan radv HAL API becomes available with hwc+gbm gralloc
V1 GPU benchmark (Vulkan API) OK
Sacha Willems examples OK
Some glitch/freeze in 3DMark Slingshot Extreeme and API overhead
Kind regards
Mauro Rossi
android-x86 team
_______________________________________________
amd-gfx mailing list
amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181008/8d828a60/attachment-0001.html>
More information about the amd-gfx
mailing list