[openchrome-users] 2D acceleration with DRM driver from drm-next-5.17

[Kevin Brace]

Hi ValdikSS,

The 2D performance of VX855 chipset (Chrome9 HCM) you are getting right now is the best you will get for now.
I have had no involvement in developing / maintaining rendering portion of the code.
My involvement is primarily limited to, mode setting and standby / resume code development along with code refactoring and other miscellaneous bug fixes, up to this point.
I think Wyse Cx0's processor is VIA Eden 1 GHz (VIA C7).
Since the processor is fairly slow, I think this makes the rendering speed subpar as well.
I think I noticed something similar to this on VX800 chipset some years ago.
I reported it, but obviously nothing happened (this is before I started contributing code).
    OpenChrome DRM is the current development focus, and getting the code mainlined (i.e., getting the code accepted by DRM maintainers) is the only focus, so acceleration support is going to be worked on after the code is mainlined.
The current timeline I have is something like this (subject to change).

1) Start initial code review by mid-June
2) Acceptance of code by mid-July (hopefully)
3) By mid to late September, OpenChrome DRM should be released with Linux 5.20

For 1, I am in the process of cleaning up the code to make it reviewable by DRM maintainers right now.
As a part of this initiative, the module name will soon revert back to "via" from "openchrome" in the near future.
The reason for this is to eliminate the legacy DRI1 VIA DRM from the mainline kernel tree.
This is technically a technological downgrade (OpenChrome DRM has no code to support DRI1 or 2, currently), but at least fulfills the minimum requirement of supporting atomic mode setting based KMS (Kernel Mode Setting) for new DRM code mainline inclusion.
Yes, this means "openchrome.modeset=1" will revert back to "via.modeset=1" for obvious reasons.
For 2, I must concede that mid-July code acceptance by DRM maintainers might be a little aggressive.
The biggest known problem of the code currently is the handling of palette / gamma correction in atomic mode setting, and for this I will likely need to seek some input from more experienced developers (I am not sure how to handle the matter.).
There could be other code related change demands from the DRM maintainers, and that will likely push the code acceptance back by another kernel release cycle (typically 8 weeks) or possibly mid-September and beyond.
For 3, it depends on 2 (obviously).
These timelines (roadmap) are not really artificial, and it is based on when X.Org + Wine Developer Conference 2022 is going to be held.

https://indico.freedesktop.org/event/2/
https://mobile.twitter.com/XOrgDevConf/status/1395383267038203905

My plan is to do presentations on how I converted legacy KMS to atomic mode setting and an update on OpenChrome Project progress.
Obviously, getting the code accepted into the mainline kernel tree before the conference will be nicer if I can pull it off.
    Regarding when I will be releasing OpenChrome DDX Version 0.7, I will release it when OpenChrome DRM is finally mainlined.
This is because I plan to update UAPI version to 4.0.x when OpenChrome DRM is mainlined, and OpenChrome DDX needs to know this.
When OpenChrome DRM module name is reverted back to "via", technically UAPI is different from "openchrome" module's UAPI (currently, Version 3.4.x).
For now, when the module name reverts back to "via", I plan to set it to 3.5.x.
There will be a new DDX released with a 500 patch level version (i.e., DDX Version 0.6.500) to handle the DRM module name reversion back to "via" and recognizing OpenChrome DRM UAPI Version 3.5.x.
After the DRM is mainlined, the UAPI will be incremented to 4.0.x.
At least that's my plan for now.
    Regarding "("Module Name").modeset=1" behavior, that is close to the original behavior (it used to be "via.modeset=1").
At one point, I removed this requirement a few years ago, but I brought it back fairly recently.
The reason for this is that even if OpenChrome DRM is finally mainlined, the code will be still be considered experimental until acceleration is supported, hence, I think it is wise to hide it behind "("Module Name").modeset=1" boot time option.
If someone really wants to use OpenChrome DRM, it should not be considered too difficult to add this boot time option to their bootloader script.
OpenChrome DRM's mode setting code is still not quite device support parity with OpenChrome DDX's UMS (Use Mode Setting) code, and this is another reason for keeping the boot time option, for now.
    Regarding the "criticism" (I am not taking it personally, ValdikSS.) "("Module Name").modeset=1" boot time option not being really documented or mentioned, something like that was mentioned by the old OpenChrome Project FreeDesktop.Org wiki page here.

https://freedesktop.org/wiki/Openchrome/TtmGemKms/

Actually, this location is not readily accessible from the wiki page (pretty much one needs to find it from a search engine), so your criticism is valid.
I do not have any involvement in maintaining the wiki page.
I did document the "("Module Name").modeset=1" boot time option when I did the code commit, but obviously this is not very easy to find or understand.

https://cgit.freedesktop.org/openchrome/drm-openchrome/commit/?h=drm-next-5.19&id=b0c9a88eca052c8384152c94a22af16e5ab03c73

I think Radeon DRM started this "("Module Name").modeset=1" boot time option more than a decade ago, and because other DRM device drivers also use them, I decided to ultimately stay with it.
I figured, if one used the same boot option name, it is easier for someone else to infer this since other DRM device drivers also use them.
    I hope I answered all of your questions and let me know if I missed anything.
Sorry, it took too long to respond.

Regards,

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


> Date: Wed, 4 May 2022 16:18:14 +0300
> From: ValdikSS <iam at valdikss.org.ru>
> To: openchrome-users at lists.freedesktop.org
> Subject: [openchrome-users] 2D acceleration with DRM driver from
> 	drm-next-5.17
> Message-ID: <4bf358c1-dd45-3052-d50e-7f30977bec04 at valdikss.org.ru>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hello everyone,
>
> I'm trying to achieve better 2D performance on WYSE C10LE thin client
> with VIA Eden Esther and VX855 video.
> Current openchrome DDX works with this video, but it's pretty slow on
> default settings, which I assume have hardware acceleration (EXA)
> enabled, at least that's what I see in xorg log.
>
> I tried to compile DRM driver from drm-next-5.17 branch, compiled the
> freshest DDX driver available, it starts but the performance is worse
> than with DDX alone, it does not have hardware acceleration enabled
> according to X log, and indeed the current DDX code disables acceleation
> if KMS is used.
>
> Kevin, you said that DRM driver requires yet unreleased 0.7 version of
> DDX driver. Do you have plans to publish it in the closest future? Or
> could you maybe send it to me in private?
>
>
> P.S. regarding running DRM driver. It requires "openchrome.modeset=1"
> kernel argument (or module argument of the same name), which is not
> stated anywhere, and X also won't start with "drmSetMaster failed" error
> if the screen is occupied with the tty - had to "systemctl stop
> getty at tty1" first.
>
>