Hi Jocelyn
Am 14.02.25 um 10:11 schrieb Jocelyn Falempe:
On 13/02/2025 10:27, Nicolas Baranger wrote:
Dear Thomas
Thanks for answer and help.
Yes, due to .date total removal in linux 6.14 (https://github.com/
torvalds/linux/commit/cb2e1c2136f71618142557ceca3a8802e87a44cd
<https:// github.com/torvalds/linux/commit/
cb2e1c2136f71618142557ceca3a8802e87a44cd>) the last DKMS sources are :
https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/
nba_last_src_20250212/src/ <https://xba.soartist.net/ast-
drm_nba_20250211/nba-dkms/nba_last_src_20250212/src/>
You can also find this sources in directory drivers/gpu/drm/ast_new
of the tarball
https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/
linux-6.14.0.1-ast1.15.1-rc2_nba0_20250212.tar.gz <https://
xba.soartist.net/ast-drm_nba_20250211/nba-kernel/linux-6.14.0.1-
ast1.15.1-rc2_nba0_20250212.tar.gz>
I'm surprised by the fact the in-kernel driver 0.1.0 is more advanced
than Aspeed version 1.15.1 because on my system it has very poor
rendering and is very slow, twinkle is high and had poor colors.
The screen flickering is high and it's like if I was using a very old
cathode ray tube monitor (In fact I'm using a SAMSUNG LCD monitor
which is perfectly functionnal and which display a nice and eyes
confortable picture when using ast 1.15.1 driver or the video output
of the Nvidia GPU ).
My testing system is a test Xeon server with an AST2400 BMC with its
AST VGA card as the main video output (to be able to have a screen on
the BMC KVM) +a discrete NVIDIA GPU I'm using for GPGPU and 3D
rendering with Nvidia prime render offload.
What I constat with embed kernel driver 0.1.0 is that the Xeon
processor is doing the video job for example when watching a video,
and it's not the case with version 1.15.1 even when displaying on the
AST VGA card a vulkan rotating cube (compute by nvidia GPU with
nvidia prime but display by the AST VGA card of the AST2400).
Note that with in-kernel version 0.1.0 it's nearly impossible to make
round the vulkan cube at more than half a round by second where it's
working (very) fine for a 32MB video memory card with version 1.15.1
as you can see in the video present in the online directory
I'm not developer or kernel developer so be sure that I wouldn't have
done all this work if the in-kernel ast version 0.1.0 was usable
out-of- the-box
Sure you can give me a patch I will test on this server (building
mainline+ast_new yesterday tooks 19 minutes on this server)
PS:
here is a 'git diff linux-6.14.0.1-ast-rc2/drivers/gpu/drm/ast
linux-6.14.0.1-ast-rc2/drivers/gpu/drm/ast_new'
https://xba.soartist.net/ast-drm_nba_20250211/nba-dump/ast-
fullpatch.patch
<https://xba.soartist.net/ast-drm_nba_20250211/nba-dump/
ast-fullpatch.patch>
Diff is about 250+ kb so the 2 drivers seems to have nothing to do
with each others...
Thanks again for help
Kind regards
Nicolas
Le 2025-02-13 08:57, Thomas Zimmermann a écrit :
Hi Nicolas
Am 12.02.25 um 19:58 schrieb Nicolas Baranger:
Dear maintener
That's mostly me and Jocelyn.
I did include ast-drm driver version 1.15.1 (in replacement of
version 0.1.0) on the new mainline kernel too (6.14.0-rc2) and I
issue a new dkms patch
Last DKMS patch had been sucessfully tested on mainline.
And last ast.ko version 1.15.1 included in linux tree had also been
sucessfully tested
Online directory is updated with :
- new DKMS patch
- new DKMS srouces
- new DKMS debian package
- new tarball of mainline included ast_new ported in kernel tree
- new kernel debian package (mainline with ast_new)
NB: online directory is here: https://xba.soartist.net/ast-
drm_nba_20250211/ <https://xba.soartist.net/ast-drm_nba_20250211/>
Please let me know what I should do to see this change in linux-next
I'm having a little trouble with figuring out which of the many
driver sources is the relevant one. Am I correct to assume it's the
one at
https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/
nba_last_src_20250212/src/ <https://xba.soartist.net/ast-
drm_nba_20250211/nba-dkms/nba_last_src_20250212/src/>
About that driver: Although the official driver reports an ancient
version number, it is an up-to-date driver. It is actually more
up-to- date than Aspeed's package. Both drivers share source code
and a few years ago there was an effort to bring the kernel's driver
up to the same feature set. Since then, the kernel's driver has been
updated, reworked and improved.
About the performance: From what I can tell, the only significant
difference in these drivers is memory management. Your ast_new
driver uses an older algorithm that we replaced quite a few releases
ago. The old version was unreliable on systems with little video
memory, so we had to replace it. I don't know why the new code
should be slower though.
Regarding the performances of ast driver, I remember doing profiling
some times ago, and when running glxgears (with llvmpipe), 65% of the
CPU time was wasted in page fault
(https://elixir.bootlin.com/linux/v6.13.2/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L534)
But as this driver is mostly used for console/basic desktop usage, I
didn't investigate more.
Now that's an interesting find. The GEM shmem helpers vunmap ASAP to
make pages swappable, I think. IIRC there was a patchset circulating
that implements a shrinker [1] for shmem helpers. With that in place,
we'd only update the page tables if necessary. If it's really that easy,
we should try to merge that.
[1]
https://elixir.bootlin.com/linux/v6.13.2/source/include/linux/shrinker.h#L82
If I remember correctly, the switch to shmem, is because some devices
have only 16MB of memory, and 1920x1200x32bits takes ~9MB, so it's not
possible to have double buffering in this case. (And this is required
by most desktop environment).
Exactly. There are ast devices with as little as 8 MiB of video memory.
But FullHD@32bit already requires ~8 MiB. Atomic modesetting with the
old memory manager requires overcommitting by a factor of 3 (to ~24 MiB)
to account for all corner cases. Hence we sometimes had failed display
updates with lower-end devices.
The switch to shmem was done with "f2fa5a99ca81c drm/ast: Convert ast
to SHMEM", and introduced in v6.2. So maybe if you can try with a v6.1
kernel, using the built-in ast driver and report if it has better
performances.
Nicolas, if you find an old kernel version that works correctly, and if
you know how to git-bisect the kernel, it would be helpful if you could
bisect to the commit that introduced the problem.
Best regards
Thomas
Best regards,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
