Re: Include ASPEED ast-drm 1.15.1 video driver in kernel tree

[Thomas Zimmermann <tzimmermann@suse.de>]

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)