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 <[email protected]>
> To: [email protected]
> Subject: [openchrome-users] 2D acceleration with DRM driver from
> drm-next-5.17
> Message-ID: <[email protected]>
> 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@tty1" first.
>
>
