Include ASPEED ast-drm 1.15.1 video driver in kernel tree

Include ASPEED ast-drm 1.15.1 video driver in kernel tree

[Nicolas Baranger]

Dear maintener

For my own usage, I did make work the ASPEED ast-drm 1.15.1 video driver 
on mainline kernel (6.13.0 + 6.13.1).

ASPEED video driver is availiable here: 
https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz

But it only work for LTS kernel 
So I modify the DKMS package and I build a new Debian DKMS package with 
the adapted  source. 
My patch can be find here :
https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch 
See the README:
https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README

Using this new 'ast 1.15.1' driver, performance are amazing compared to 
the 'ast' driver include in kernel tree, specially when using a discrete 
GPU and offloading VULKAN / 3D on it but using AST VGA card as the main 
video card and as the main and only video output (the discrete GPU is 
used only for offloading 3D or for cuda/opencl)


So to make things easier, I include the new 'ast 1.15.1' driver in 
kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
It's working fine as you can see on this video : 
https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 

I upload all the work I've done here :
https://xba.soartist.net/ast-drm_nba_20250211/

See the global README :
https://xba.soartist.net/ast-drm_nba_20250211/README

and the README in nba-kernel sub-directory :
https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README

I'm not a developer so please let me know if I made the things the right 
way and if this new 'ast 1.15.1' driver can be ported to linux-next or 
linux-? ?
If you need more explanations, do not hesitate to contact me, I would be 
happy to help

Kind regards
Nicolas Baranger

Include ASPEED ast-drm 1.15.1 video driver in kernel tree

[Nicolas Baranger]

Dear maintener

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/

Please let me know what I should do to see this change in linux-next

Thanks for help

Kind regards
Nicolas Baranger


Le 2025-02-11 19:15, Nicolas Baranger a écrit :

> Dear maintener
> 
> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
> driver on mainline kernel (6.13.0 + 6.13.1).
> 
> ASPEED video driver is availiable here:
> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
> 
> But it only work for LTS kernel
> So I modify the DKMS package and I build a new Debian DKMS package with 
> the adapted  source.
> My patch can be find here :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
> See the README:
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
> 
> Using this new 'ast 1.15.1' driver, performance are amazing compared to 
> the 'ast' driver include in kernel tree, specially when using a 
> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card as 
> the main video card and as the main and only video output (the discrete 
> GPU is used only for offloading 3D or for cuda/opencl)
> 
> So to make things easier, I include the new 'ast 1.15.1' driver in 
> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
> It's working fine as you can see on this video :
> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm
> 
> I upload all the work I've done here :
> https://xba.soartist.net/ast-drm_nba_20250211/
> 
> See the global README :
> https://xba.soartist.net/ast-drm_nba_20250211/README
> 
> and the README in nba-kernel sub-directory :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
> 
> I'm not a developer so please let me know if I made the things the 
> right way and if this new 'ast 1.15.1' driver can be ported to 
> linux-next or linux-? ?
> If you need more explanations, do not hesitate to contact me, I would 
> be happy to help
> 
> Kind regards
> Nicolas Baranger

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

[Maarten Lankhorst]

Hello Nicolas,

Thank you for taking a look at this. It would be nice to have an updated 
driver. The best way to go forward is to chop the enhancements from the 
version that you tested into small patches that can be applied to the 
kernel tree.

This way you get all the benefits from the updated driver, in a way that 
it's suitable to maintain for us.

Kind regards,
Maarten Lankhorst

On 2025-02-12 19:58, Nicolas Baranger wrote:
> Dear maintener
> 
> 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/
> 
> Please let me know what I should do to see this change in linux-next
> 
> Thanks for help
> 
> Kind regards
> Nicolas Baranger
> 
> 
> Le 2025-02-11 19:15, Nicolas Baranger a écrit :
> 
>> Dear maintener
>>
>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>> driver on mainline kernel (6.13.0 + 6.13.1).
>>
>> ASPEED video driver is availiable here:
>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>>
>> But it only work for LTS kernel
>> So I modify the DKMS package and I build a new Debian DKMS package 
>> with the adapted  source.
>> My patch can be find here :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
>> See the README:
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>>
>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>> to the 'ast' driver include in kernel tree, specially when using a 
>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>> as the main video card and as the main and only video output (the 
>> discrete GPU is used only for offloading 3D or for cuda/opencl)
>>
>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>> It's working fine as you can see on this video :
>> https://xba.soartist.net/ast-drm_nba_20250211/ 
>> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm
>>
>> I upload all the work I've done here :
>> https://xba.soartist.net/ast-drm_nba_20250211/
>>
>> See the global README :
>> https://xba.soartist.net/ast-drm_nba_20250211/README
>>
>> and the README in nba-kernel sub-directory :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>>
>> I'm not a developer so please let me know if I made the things the 
>> right way and if this new 'ast 1.15.1' driver can be ported to linux- 
>> next or linux-? ?
>> If you need more explanations, do not hesitate to contact me, I would 
>> be happy to help
>>
>> Kind regards
>> Nicolas Baranger

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

[Thomas Zimmermann]

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/
>
> 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/


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.

If I give you a patch against a recent Linux kernel, are you capable of 
building the patched kernel and testing that change on your system?

Best regards
Thomas


>
> Thanks for help
>
> Kind regards
> Nicolas Baranger
>
>
> Le 2025-02-11 19:15, Nicolas Baranger a écrit :
>
>> Dear maintener
>>
>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>> driver on mainline kernel (6.13.0 + 6.13.1).
>>
>> ASPEED video driver is availiable here:
>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>>
>> But it only work for LTS kernel
>> So I modify the DKMS package and I build a new Debian DKMS package 
>> with the adapted  source.
>> My patch can be find here :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
>> See the README:
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>>
>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>> to the 'ast' driver include in kernel tree, specially when using a 
>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>> as the main video card and as the main and only video output (the 
>> discrete GPU is used only for offloading 3D or for cuda/opencl)
>>
>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>> It's working fine as you can see on this video :
>> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
>>
>>
>> I upload all the work I've done here :
>> https://xba.soartist.net/ast-drm_nba_20250211/
>>
>> See the global README :
>> https://xba.soartist.net/ast-drm_nba_20250211/README
>>
>> and the README in nba-kernel sub-directory :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>>
>> I'm not a developer so please let me know if I made the things the 
>> right way and if this new 'ast 1.15.1' driver can be ported to 
>> linux-next or linux-? ?
>> If you need more explanations, do not hesitate to contact me, I would 
>> be happy to help
>>
>> Kind regards
>> Nicolas Baranger

-- 
--
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)

Include ASPEED ast-drm 1.15.1 video driver in kernel tree

[Nicolas Baranger]

[-- Attachment #1: Type: text/plain, Size: 6414 bytes --]



Dear Thomas

Thanks for answer and help.

Yes, due to .date total removal in linux 6.14 
(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/

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

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
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/
>> 
>> 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/
> 
> 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.
> 
> If I give you a patch against a recent Linux kernel, are you capable of 
> building the patched kernel and testing that change on your system?
> 
> Best regards
> Thomas
> 
> Thanks for help
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-11 19:15, Nicolas Baranger a écrit :
> 
> Dear maintener
> 
> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
> driver on mainline kernel (6.13.0 + 6.13.1).
> 
> ASPEED video driver is availiable here:
> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
> 
> But it only work for LTS kernel
> So I modify the DKMS package and I build a new Debian DKMS package with 
> the adapted  source.
> My patch can be find here :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
> See the README:
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
> 
> Using this new 'ast 1.15.1' driver, performance are amazing compared to 
> the 'ast' driver include in kernel tree, specially when using a 
> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card as 
> the main video card and as the main and only video output (the discrete 
> GPU is used only for offloading 3D or for cuda/opencl)
> 
> So to make things easier, I include the new 'ast 1.15.1' driver in 
> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
> It's working fine as you can see on this video :
> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
> I upload all the work I've done here :
> https://xba.soartist.net/ast-drm_nba_20250211/
> 
> See the global README :
> https://xba.soartist.net/ast-drm_nba_20250211/README
> 
> and the README in nba-kernel sub-directory :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
> 
> I'm not a developer so please let me know if I made the things the 
> right way and if this new 'ast 1.15.1' driver can be ported to 
> linux-next or linux-? ?
> If you need more explanations, do not hesitate to contact me, I would 
> be happy to help
> 
> Kind regards
> Nicolas Baranger

[-- Attachment #2: Type: text/html, Size: 11260 bytes --]

Include ASPEED ast-drm 1.15.1 video driver in kernel tree

[Nicolas Baranger]

Sorry for the noise, html was rejected by linux-kernel@vger.kernel.org 
so resending this mail in plain text

Regards
Nicolas

Le 2025-02-13 10:27, Nicolas Baranger a écrit :

> Dear Thomas
> 
> Thanks for answer and help.
> 
> Yes, due to .date total removal in linux 6.14 
> (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/
> 
> 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
> 
> 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
> 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/
> 
> 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/
> 
> 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.
> 
> If I give you a patch against a recent Linux kernel, are you capable of 
> building the patched kernel and testing that change on your system?
> 
> Best regards
> Thomas
> 
> Thanks for help
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-11 19:15, Nicolas Baranger a écrit :
> 
> Dear maintener
> 
> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
> driver on mainline kernel (6.13.0 + 6.13.1).
> 
> ASPEED video driver is availiable here:
> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
> 
> But it only work for LTS kernel
> So I modify the DKMS package and I build a new Debian DKMS package with 
> the adapted  source.
> My patch can be find here :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
> See the README:
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
> 
> Using this new 'ast 1.15.1' driver, performance are amazing compared to 
> the 'ast' driver include in kernel tree, specially when using a 
> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card as 
> the main video card and as the main and only video output (the discrete 
> GPU is used only for offloading 3D or for cuda/opencl)
> 
> So to make things easier, I include the new 'ast 1.15.1' driver in 
> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
> It's working fine as you can see on this video :
> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
> I upload all the work I've done here :
> https://xba.soartist.net/ast-drm_nba_20250211/
> 
> See the global README :
> https://xba.soartist.net/ast-drm_nba_20250211/README
> 
> and the README in nba-kernel sub-directory :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
> 
> I'm not a developer so please let me know if I made the things the 
> right way and if this new 'ast 1.15.1' driver can be ported to 
> linux-next or linux-? ?
> If you need more explanations, do not hesitate to contact me, I would 
> be happy to help
> 
> Kind regards
> Nicolas Baranger

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

[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.

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).

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.

Best regards,

-- 

Jocelyn

>>
>> If I give you a patch against a recent Linux kernel, are you capable 
>> of building the patched kernel and testing that change on your system?
>>
>> Best regards
>> Thomas
>>
>>
>>>
>>> Thanks for help
>>>
>>> Kind regards
>>> Nicolas Baranger
>>>
>>>
>>> Le 2025-02-11 19:15, Nicolas Baranger a écrit :
>>>
>>>> Dear maintener
>>>>
>>>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>>>> driver on mainline kernel (6.13.0 + 6.13.1).
>>>>
>>>> ASPEED video driver is availiable here:
>>>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz 
>>>> <https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz>
>>>>
>>>> But it only work for LTS kernel
>>>> So I modify the DKMS package and I build a new Debian DKMS package 
>>>> with the adapted  source.
>>>> My patch can be find here :
>>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch 
>>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch>
>>>> See the README:
>>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README 
>>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README>
>>>>
>>>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>>>> to the 'ast' driver include in kernel tree, specially when using a 
>>>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>>>> as the main video card and as the main and only video output (the 
>>>> discrete GPU is used only for offloading 3D or for cuda/opencl)
>>>>
>>>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>>>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>>>> It's working fine as you can see on this video :
>>>> https://xba.soartist.net/ast-drm_nba_20250211/ 
>>>> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm <https:// 
>>>> xba.soartist.net/ast-drm_nba_20250211/ 
>>>> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm> I upload 
>>>> all the work I've done here :
>>>> https://xba.soartist.net/ast-drm_nba_20250211/ <https:// 
>>>> xba.soartist.net/ast-drm_nba_20250211/>
>>>>
>>>> See the global README :
>>>> https://xba.soartist.net/ast-drm_nba_20250211/README <https:// 
>>>> xba.soartist.net/ast-drm_nba_20250211/README>
>>>>
>>>> and the README in nba-kernel sub-directory :
>>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README 
>>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README>
>>>>
>>>> I'm not a developer so please let me know if I made the things the 
>>>> right way and if this new 'ast 1.15.1' driver can be ported to 
>>>> linux-next or linux-? ?
>>>> If you need more explanations, do not hesitate to contact me, I 
>>>> would be happy to help
>>>>
>>>> Kind regards
>>>> Nicolas Baranger

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

[Nicolas Baranger]

[-- Attachment #1: Type: text/plain, Size: 10339 bytes --]

Dear JocelynThanks for answer and help Ok, I will try linux 6.1 (could you confirm that every commit in 6.1 before 965361 should be relevant ?)If I need to have "~correct or better to say 'acceptable' year 2025 performances~" on AST2400 VGA card it's because at the hardware level if I select the NVIDIA discrete GPU as the main server video output, I lost all the server management benefits and capabilities of the AST2400 BMC (except PSU management) as I get a black screen... And it's dangerous as keyboard and mouse keep working on the black screen and so, can launch destructive actions without knowing it !Also I'm still surprise by Thomas answer as the aspeed drm drivers 1.15.1 is dated of December 2024... And Jammy Huang from AspeedTech teold me to contact here to upstream the ast_new adaptation I've made after he knows that I did version 1.15.1 work on mainline (Aspeed only support LTS kernel and their dkms package were not usable out-of-the-box on mainline)I may surely be wrong and some explanations could help me to understand which is the actual situation of ast driver in kernel tree.I would let you know the results in 6.1Again thanks a lot for help !Kind regards, Nicolas Baranger 
-------- Message d'origine --------De : Jocelyn Falempe <jfalempe@redhat.com> Date : 14/02/2025  10:11  (GMT+01:00) À : Nicolas Baranger <nicolas.baranger@3xo.fr>, Thomas Zimmermann <tzimmermann@suse.de> Cc : dri-devel@lists.freedesktop.org, airlied@redhat.com, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>, linux-kernel@vger.kernel.org Objet : Re: Include ASPEED ast-drm 1.15.1 video driver in kernel tree 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.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).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.Best regards,-- Jocelyn>>>> If I give you a patch against a recent Linux kernel, are you capable >> of building the patched kernel and testing that change on your system?>>>> Best regards>> Thomas>>>>>>>>>> Thanks for help>>>>>> Kind regards>>> Nicolas Baranger>>>>>>>>> Le 2025-02-11 19:15, Nicolas Baranger a écrit :>>>>>>> Dear maintener>>>>>>>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video >>>> driver on mainline kernel (6.13.0 + 6.13.1).>>>>>>>> ASPEED video driver is availiable here:>>>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz >>>> <https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz>>>>>>>>> But it only work for LTS kernel>>>> So I modify the DKMS package and I build a new Debian DKMS package >>>> with the adapted  source.>>>> My patch can be find here :>>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch >>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch>>>>> See the README:>>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README >>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README>>>>>>>>> Using this new 'ast 1.15.1' driver, performance are amazing compared >>>> to the 'ast' driver include in kernel tree, specially when using a >>>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card >>>> as the main video card and as the main and only video output (the >>>> discrete GPU is used only for offloading 3D or for cuda/opencl)>>>>>>>> So to make things easier, I include the new 'ast 1.15.1' driver in >>>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'>>>> It's working fine as you can see on this video :>>>> https://xba.soartist.net/ast-drm_nba_20250211/ >>>> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm <https:// >>>> xba.soartist.net/ast-drm_nba_20250211/ >>>> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm> I upload >>>> all the work I've done here :>>>> https://xba.soartist.net/ast-drm_nba_20250211/ <https:// >>>> xba.soartist.net/ast-drm_nba_20250211/>>>>>>>>> See the global README :>>>> https://xba.soartist.net/ast-drm_nba_20250211/README <https:// >>>> xba.soartist.net/ast-drm_nba_20250211/README>>>>>>>>> and the README in nba-kernel sub-directory :>>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README >>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README>>>>>>>>> I'm not a developer so please let me know if I made the things the >>>> right way and if this new 'ast 1.15.1' driver can be ported to >>>> linux-next or linux-? ?>>>> If you need more explanations, do not hesitate to contact me, I >>>> would be happy to help>>>>>>>> Kind regards>>>> Nicolas Baranger

[-- Attachment #2: Type: text/html, Size: 13977 bytes --]

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

[Thomas Zimmermann]

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)

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

[Thomas Zimmermann]

Hi

Am 14.02.25 um 13:09 schrieb Nicolas Baranger:
> Dear Jocelyn
>
> Thanks for answer and help
>
> Ok, I will try linux 6.1 (could you confirm that every commit in 6.1 
> before 965361 should be relevant ?)
>
> If I need to have "~correct or better to say 'acceptable' year 2025 
> performances~" on AST2400 VGA card it's because at the hardware level 
> if I select the NVIDIA discrete GPU as the main server video output, I 
> lost all the server management benefits and capabilities of the 
> AST2400 BMC (except PSU management) as I get a black screen... And 
> it's dangerous as keyboard and mouse keep working on the black screen 
> and so, can launch destructive actions without knowing it !
>
> Also I'm still surprise by Thomas answer as the aspeed drm drivers 
> 1.15.1 is dated of December 2024...

Well, I cannot find a difference except for the old memory management. 
Aspeed has meanwhile also contributed patches to the upstream kernel. 
They might cover some of the differences. I also noticed that the Aspeed 
driver for v6.6 seems to use the newer memory management.

> And Jammy Huang from AspeedTech teold me to contact here to upstream 
> the ast_new adaptation I've made after he knows that I did version 
> 1.15.1 work on mainline (Aspeed only support LTS kernel and their dkms 
> package were not usable out-of-the-box on mainline)
>
> I may surely be wrong and some explanations could help me to 
> understand which is the actual situation of ast driver in kernel tree.

We're not going to merge a second driver for hardware we already 
support. The upstream kernel's driver is the one we should improve. I'm 
glad for the bug report and information you already provided. If you 
want to help with further testing and, you're welcome to do so.

Best regards
Thomas

>
> I would let you know the results in 6.1
>
> Again thanks a lot for help !
>
> Kind regards,
> Nicolas Baranger
>
>
> -------- Message d'origine --------
> De : Jocelyn Falempe <jfalempe@redhat.com>
> Date : 14/02/2025 10:11 (GMT+01:00)
> À : Nicolas Baranger <nicolas.baranger@3xo.fr>, Thomas Zimmermann 
> <tzimmermann@suse.de>
> Cc : dri-devel@lists.freedesktop.org, airlied@redhat.com, Maarten 
> Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard 
> <mripard@kernel.org>, David Airlie <airlied@gmail.com>, Simona Vetter 
> <simona@ffwll.ch>, linux-kernel@vger.kernel.org
> Objet : Re: Include ASPEED ast-drm 1.15.1 video driver in kernel tree
>
> 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.
>
> 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).
>
> 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.
>
> Best regards,
>
> -- 
>
> Jocelyn
>
> >>
> >> If I give you a patch against a recent Linux kernel, are you capable
> >> of building the patched kernel and testing that change on your system?
> >>
> >> Best regards
> >> Thomas
> >>
> >>
> >>>
> >>> Thanks for help
> >>>
> >>> Kind regards
> >>> Nicolas Baranger
> >>>
> >>>
> >>> Le 2025-02-11 19:15, Nicolas Baranger a écrit :
> >>>
> >>>> Dear maintener
> >>>>
> >>>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video
> >>>> driver on mainline kernel (6.13.0 + 6.13.1).
> >>>>
> >>>> ASPEED video driver is availiable here:
> >>>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
> >>>> <https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz>
> >>>>
> >>>> But it only work for LTS kernel
> >>>> So I modify the DKMS package and I build a new Debian DKMS package
> >>>> with the adapted  source.
> >>>> My patch can be find here :
> >>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
> >>>> 
> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch>
> >>>> See the README:
> >>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
> >>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README>
> >>>>
> >>>> Using this new 'ast 1.15.1' driver, performance are amazing compared
> >>>> to the 'ast' driver include in kernel tree, specially when using a
> >>>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card
> >>>> as the main video card and as the main and only video output (the
> >>>> discrete GPU is used only for offloading 3D or for cuda/opencl)
> >>>>
> >>>> So to make things easier, I include the new 'ast 1.15.1' driver in
> >>>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
> >>>> It's working fine as you can see on this video :
> >>>> https://xba.soartist.net/ast-drm_nba_20250211/
> >>>> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm <https://
> >>>> xba.soartist.net/ast-drm_nba_20250211/
> >>>> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm> I upload
> >>>> all the work I've done here :
> >>>> https://xba.soartist.net/ast-drm_nba_20250211/ <https://
> >>>> xba.soartist.net/ast-drm_nba_20250211/>
> >>>>
> >>>> See the global README :
> >>>> https://xba.soartist.net/ast-drm_nba_20250211/README <https://
> >>>> xba.soartist.net/ast-drm_nba_20250211/README>
> >>>>
> >>>> and the README in nba-kernel sub-directory :
> >>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
> >>>> <https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README>
> >>>>
> >>>> I'm not a developer so please let me know if I made the things the
> >>>> right way and if this new 'ast 1.15.1' driver can be ported to
> >>>> linux-next or linux-? ?
> >>>> If you need more explanations, do not hesitate to contact me, I
> >>>> would be happy to help
> >>>>
> >>>> Kind regards
> >>>> Nicolas Baranger
>

-- 
--
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)

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

[Nicolas Baranger]

Hi Thomas

Thanks again for help

> 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.

Ok, I will try to find a working kernel and to git bisect to find the 
commit which introduce the problem.
I will start with longterm 6.1.128

Kind regards
Nicolas



> Le 2025-02-14 13:36, Thomas Zimmermann a écrit :
> 
>> 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,

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

[Nicolas Baranger]

Hi Thomas

> We're not going to merge a second driver for hardware we already 
> support. The upstream kernel's driver is the one we should improve. I'm 
> glad for the bug report and information you already provided. If you 
> want to help with further testing and, you're welcome to do so.

Sure I understand !
No problems to continue testing or whatever could help

Thanks again
Kind regards
Nicolas Baranger


Le 2025-02-14 13:46, Thomas Zimmermann a écrit :

> Hi
> 
> Am 14.02.25 um 13:09 schrieb Nicolas Baranger:
> 
>> Dear Jocelyn
>> 
>> Thanks for answer and help
>> 
>> Ok, I will try linux 6.1 (could you confirm that every commit in 6.1 
>> before 965361 should be relevant ?)
>> 
>> If I need to have "~correct or better to say 'acceptable' year 2025 
>> performances~" on AST2400 VGA card it's because at the hardware level 
>> if I select the NVIDIA discrete GPU as the main server video output, I 
>> lost all the server management benefits and capabilities of the 
>> AST2400 BMC (except PSU management) as I get a black screen... And 
>> it's dangerous as keyboard and mouse keep working on the black screen 
>> and so, can launch destructive actions without knowing it !
>> 
>> Also I'm still surprise by Thomas answer as the aspeed drm drivers 
>> 1.15.1 is dated of December 2024...
> 
> Well, I cannot find a difference except for the old memory management. 
> Aspeed has meanwhile also contributed patches to the upstream kernel. 
> They might cover some of the differences. I also noticed that the 
> Aspeed driver for v6.6 seems to use the newer memory management.
> 
>> And Jammy Huang from AspeedTech teold me to contact here to upstream 
>> the ast_new adaptation I've made after he knows that I did version 
>> 1.15.1 work on mainline (Aspeed only support LTS kernel and their dkms 
>> package were not usable out-of-the-box on mainline)
>> 
>> I may surely be wrong and some explanations could help me to 
>> understand which is the actual situation of ast driver in kernel tree.
> 
> We're not going to merge a second driver for hardware we already 
> support. The upstream kernel's driver is the one we should improve. I'm 
> glad for the bug report and information you already provided. If you 
> want to help with further testing and, you're welcome to do so.
> 
> Best regards
> Thomas
> 
> I would let you know the results in 6.1
> 
> Again thanks a lot for help !
> 
> Kind regards,
> Nicolas Baranger
> 
> -------- Message d'origine --------
> De : Jocelyn Falempe <jfalempe@redhat.com>
> Date : 14/02/2025 10:11 (GMT+01:00)
> À : Nicolas Baranger <nicolas.baranger@3xo.fr>, Thomas Zimmermann 
> <tzimmermann@suse.de>
> Cc : dri-devel@lists.freedesktop.org, airlied@redhat.com, Maarten 
> Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard 
> <mripard@kernel.org>, David Airlie <airlied@gmail.com>, Simona Vetter 
> <simona@ffwll.ch>, linux-kernel@vger.kernel.org
> Objet : Re: Include ASPEED ast-drm 1.15.1 video driver in kernel tree
> 
> 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.

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).

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.

Best regards,

-- Jocelyn

> If I give you a patch against a recent Linux kernel, are you capable
> of building the patched kernel and testing that change on your system?
> 
> Best regards
> Thomas
> 
> Thanks for help
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-11 19:15, Nicolas Baranger a écrit :
> 
> Dear maintener
> 
> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video
> driver on mainline kernel (6.13.0 + 6.13.1).
> 
> ASPEED video driver is availiable here:
> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
> <https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz>
> 
> But it only work for LTS kernel
> So I modify the DKMS package and I build a new Debian DKMS package
> with the adapted  source.
> My patch can be find here :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch>
> See the README:
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
> <https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README>
> 
> Using this new 'ast 1.15.1' driver, performance are amazing compared
> to the 'ast' driver include in kernel tree, specially when using a
> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card
> as the main video card and as the main and only video output (the
> discrete GPU is used only for offloading 3D or for cuda/opencl)
> 
> So to make things easier, I include the new 'ast 1.15.1' driver in
> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
> It's working fine as you can see on this video :
> https://xba.soartist.net/ast-drm_nba_20250211/
> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm <https://
> xba.soartist.net/ast-drm_nba_20250211/
> vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm> I upload
> all the work I've done here :
> https://xba.soartist.net/ast-drm_nba_20250211/ <https://
> xba.soartist.net/ast-drm_nba_20250211/>
> 
> See the global README :
> https://xba.soartist.net/ast-drm_nba_20250211/README <https://
> xba.soartist.net/ast-drm_nba_20250211/README>
> 
> and the README in nba-kernel sub-directory :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
> <https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README>
> 
> I'm not a developer so please let me know if I made the things the
> right way and if this new 'ast 1.15.1' driver can be ported to
> linux-next or linux-? ?
> If you need more explanations, do not hesitate to contact me, I
> would be happy to help
> 
> Kind regards
> Nicolas Baranger

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

[Nicolas Baranger]

Hi Thomas, Jocelyn

Starting with 6.1.128 longterm kernel failed and it seems to be a 'drm 
error'

Xorg error :

(==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 14 17:32:59 2025
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor "<default monitor>"
(==) No monitor specified for screen "Default Screen Section".
a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(==) Automatically adding GPU devices
(==) Automatically binding GPU devices
(==) Max clients allowed: 256, resource mask: 0x1fffff
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
	Entry deleted from font path.
(==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) The server relies on udev to provide the list of input devices.
no devices become available, reconfigure udev or disable AutoAddDevices.
(II) Loader magic: 0x561372a83f00
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 25.2
	X.Org XInput driver : 24.4
	X.Org Server Extension : 10.0
(++) using VT number 1

(II) systemd-logind: took control of session 
/org/freedesktop/login1/session/c13
(II) xfree86: Adding drm device (/dev/dri/card1)
(II) Platform probe for 
/sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/drm/card1
(II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 14 paused 0
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5613729f7f79]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
[0x7f0dad05b050]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (__nss_database_lookup+0xcd19) 
[0x7f0dad17m.so.2 (drmGetVe728e67a4]
(EE) 6: /usr/lib/xorg/Xorg (xf86PlatformDeviceCheckBusID+0x1bb) 
[0x5613728e6aab]
(EE) 7: /usr/lib/xorg/Xorg (config_fini+0x19b7) [0x5613728e3a97]
(EE) 8: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x1b5) 
[0x5613728e0615]
(EE) 9: /usr/lib/xorg/Xorg (xf86BusProbe+0x9) [0x5613728b9329]
(EE) 10: /usr/lib/xorg/Xorg (InitOutput+0x69a) [0x5613728c72ca]
(EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x56137288866e]
(EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
[0x7f0dad04624a]
(EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
[0x7f0dad046305]
(EE) 14: /usr/lib/xorg/Xorg (_start+0x21) [0x561372871b71]
(EE)
(EE) Segmentation fault at address 0x0
(EE)
server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
(EE)
consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.


Kernel trace :

------------[ cut here ]------------
BUG: the value to copy was not set!
WARNING: CPU: 10 PID: 6240 at drivers/gpu/drm/drm_ioctl.c:478 
drm_copy_field+0xa2/0xb0 [drm]
Modules linked in: xt_CHECKSUM(E) xt_MASQUERADE(E) xt_conntrack(E) 
ipt_REJECT(E) nf_reject_ipv4(E) xt_tcpudp(E) nft_compat(E) 
nft_chain_nat(E) nf_tables(E) nls_utf8(E) nfnetlink(E) 
cpufreq_userspace(E) cifs(E) l2tp_ppp(E) cifs_arc4(E) l2tp_netlink(E) 
cpufreq_ondemand(E) rdma_cm(E) l2tp_core(E) iw_cm(E) ip6_udp_tunnel(E) 
udp_tunnel(E) cpufreq_conservative(E) ib_cm(E) pppox(E) ppp_generic(E) 
slhc(E) ib_core(E) cifs_md4(E) dns_resolver(E) cpufreq_powersave(E) 
xfrm_user(E) xfrm_algo(E) scsi_transport_iscsi(E) nvme_fabrics(E) 
team_mode_loadbalance(E) 8021q(E) garp(E) mrp(E) team(E) bridge(E) 
stp(E) llc(E) qrtr(E) openvswitch(E) nsh(E) nf_conncount(E) nf_nat(E) 
nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) cmac(E) 
algif_hash(E) algif_skcipher(E) af_alg(E) bnep(E) binfmt_misc(E) 
nls_ascii(E) nls_cp437(E) vfat(E) fat(E) ext4(E) mbcache(E) jbd2(E) 
intel_rapl_msr(E) intel_rapl_common(E) nvidia_drm(POE) 
snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E)
  nvidia_modeset(POE) intel_uncore_frequency(E) 
intel_uncore_frequency_common(E) sb_edac(E) btusb(E) snd_hda_intel(E) 
btrtl(E) snd_usb_audio(E) x86_pkg_temp_thermal(E) btbcm(E) 
snd_intel_dspcfg(E) snd_intel_sdw_acpi(E) intel_powerclamp(E) 
snd_usbmidi_lib(E) btintel(E) snd_rawmidi(E) coretemp(E) btmtk(E) 
snd_seq_device(E) snd_hda_codec(E) nvidia(POE) eeepc_wmi(E) 
snd_hda_core(E) mc(E) snd_pcsp(E) snd_hwdep(E) rapl(E) asus_wmi(E) 
ipmi_ssif(E) battery(E) iTCO_wdt(E) bluetooth(E) intel_cstate(E) 
snd_pcm(E) sparse_keymap(E) ledtrig_audio(E) snd_timer(E) 
intel_pmc_bxt(E) acpi_ipmi(E) platform_profile(E) intel_uncore(E) 
crc16(E) wmi_bmof(E) rfkill(E) mei_me(E) iTCO_vendor_support(E) 
ipmi_si(E) snd(E) watchdog(E) mei(E) video(E) soundcore(E) 
ipmi_devintf(E) ipmi_msghandler(E) joydev(E) evdev(E) sg(E) msr(E) 
parport_pc(E) ppdev(E) nfsd(E) lp(E) parport(E) auth_rpcgss(E) 
nfs_acl(E) lockd(E) grace(E) loop(E) efi_pstore(E) configfs(E) sunrpc(E) 
ip_tables(E) x_tables(E) autofs4(E)
  btrfs(E) blake2b_generic(E) zstd_compress(E) efivarfs(E) raid10(E) 
sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_plantronics(E) 
hid_logitech_dj(E) hid_generic(E) uas(E) usbhid(E) hid(E) usb_storage(E) 
raid456(E) async_raid6_recov(E) async_memcpy(E) async_pq(E) async_xor(E) 
async_tx(E) xor(E) raid1(E) raid0(E) raid6_pq(E) dm_mod(E) 
crc32c_intel(E) md_mod(E) sd_mod(E) ast(E) drm_vram_helper(E) 
drm_ttm_helper(E) ghash_clmulni_intel(E) ttm(E) sha512_ssse3(E) 
sha256_ssse3(E) drm_kms_helper(E) sha1_ssse3(E) ahci(E) libahci(E) 
xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) aesni_intel(E) nvme(E) 
mxm_wmi(E) igb(E) libata(E) crypto_simd(E) i2c_i801(E) cryptd(E) drm(E) 
dca(E) i2c_smbus(E) lpc_ich(E) usbcore(E) scsi_mod(E) i2c_algo_bit(E) 
nvme_core(E) t10_pi(E) usb_common(E) scsi_common(E) i40e(E) wmi(E) 
button(E)
CPU: 10 PID: 6240 Comm: Xorg Tainted: P           OE      6.1.128-amd64 
#0
Hardware name: ASUS All Series/X99-WS/IPMI, BIOS 4001 05/28/2019
RIP: 0010:drm_copy_field+0xa2/0xb0 [drm]
Code: 00 00 74 13 49 c7 45 00 00 00 00 00 eb e0 0f 0b b8 f2 ff ff ff eb 
d9 48 c7 c7 70 cb 17 c1 c6 05 43 17 07 00 01 e8 2e 09 57 dd <0f> 0b eb 
d6 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 0f 1f 44 00
RSP: 0018:ffffbd9941b0fba8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffffbd9941b0fc60 RCX: 0000000000000027
RDX: ffff9ec3bf6a13a8 RSI: 0000000000000001 RDI: ffff9ec3bf6a13a0
RBP: ffff9e8487476800 R08: 0000000000000000 R09: ffffbd9941b0fa20
R10: 0000000000000003 R11: ffff9ec3bff15ee8 R12: ffffffffc1132570
R13: ffffbd9941b0fc80 R14: ffff9e85881d7200 R15: 0000000000000040
FS:  00007f59dd209ac0(0000) GS:ffff9ec3bf680000(0000) 
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056272a2123d0 CR3: 000000010c396005 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  <TASK>
  ? __warn+0x81/0xd0
  ? drm_copy_field+0xa2/0xb0 [drm]
  ? report_bug+0xe6/0x150
  ? handle_bug+0x41/0x70
  ? exc_invalid_op+0x17/0x70
  ? asm_exc_invalid_op+0x1a/0x20
  ? drm_ioctl_flags+0x50/0x50 [drm]
  ? drm_copy_field+0xa2/0xb0 [drm]
  ? drm_copy_field+0xa2/0xb0 [drm]
  ? drm_ioctl_flags+0x50/0x50 [drm]
  drm_version+0x73/0xa0 [drm]
  drm_ioctl_kernel+0xcd/0x170 [drm]
  drm_ioctl+0x233/0x410 [drm]
  ? drm_ioctl_flags+0x50/0x50 [drm]
  __x64_sys_ioctl+0x94/0xd0
  do_syscall_64+0x59/0xb0
  ? vfs_write+0x2b1/0x3f0
  ? vfs_write+0x2b1/0x3f0
  ? ksys_write+0x6f/0xf0
  ? exit_to_user_mode_prepare+0x40/0x1e0
  ? syscall_exit_to_user_mode+0x22/0x40
  ? do_syscall_64+0x65/0xb0
  ? __x64_sys_fcntl+0x94/0xc0
  ? exit_to_user_mode_prepare+0x40/0x1e0
  ? syscall_exit_to_user_mode+0x22/0x40
  ? do_syscall_64+0x65/0xb0
  ? syscall_exit_to_user_mode+0x22/0x40
  ? do_syscall_64+0x65/0xb0
  ? exit_to_user_mode_prepare+0x40/0x1e0
  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
RIP: 0033:0x7f59dd31ccdb
Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 
44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 
00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
RSP: 002b:00007fff22f5d440 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000056272a211f10 RCX: 00007f59dd31ccdb
RDX: 000056272a211f10 RSI: 00000000c0406400 RDI: 000000000000000e
RBP: 000056272a211f10 R08: 00007f59dd3f1cc0 R09: 0000000000000070
R10: 00007f59dd236378 R11: 0000000000000246 R12: 00000000c0406400
R13: 000000000000000e R14: 000000000000000e R15: 000056272a211510
  </TASK>
---[ end trace 0000000000000000 ]---

Maybe my Xorg is too recent (but I hope not) as I don't want to 
downgrade Xorg (nor reinstall an older debian version) so I will try 
another kernel version...
6.1.128 was build by me and maybe the 'make olddefconfig' from mainline 
to 6.1.128 lost too many options (for ex 
device-drivers/graphic-support>drm does not exist in menuconfig and I 
found AST module directly in device-drivers/graphic-support ...)
6.1.124 exist prepackaged by Debian so it .config should be more generic 
so I will test it

Thanks again for help,

Kind regards
Nicolas Baranger

Le 2025-02-14 16:01, Nicolas Baranger a écrit :

> Hi Thomas
> 
> Thanks again for help
> 
>> 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.
> 
> Ok, I will try to find a working kernel and to git bisect to find the 
> commit which introduce the problem.
> I will start with longterm 6.1.128
> 
> Kind regards
> Nicolas
> 
> Le 2025-02-14 13:36, Thomas Zimmermann a écrit :
> 
> 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,

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

[Nicolas Baranger]

Hi Thomas, Jocelyn

Same error with linux-6.1.124 debian package ...
It's reported in log as a drm bug by kernel:

------------[ cut here ]------------
BUG: the value to copy was not set!
WARNING: CPU: 13 PID: 6163 at drivers/gpu/drm/drm_ioctl.c:478 
drm_copy_field+0xa2/0xb0 [drm]

This server had already work with Linux 6.1 in the past so I don't know 
what to think...
The last linux-6.1 version I'm sure that had work on this server was 
6.1.85 (according to my post here 
https://bugzilla.kernel.org/show_bug.cgi?id=219480#c3)

Maybe I should install a new Debian system on a usb stick for doing 
tests

Going back here with next results
Thanks again for help


Kind regards,
Nicolas Baranger



Le 2025-02-14 18:03, Nicolas Baranger a écrit :

> Hi Thomas, Jocelyn
> 
> Starting with 6.1.128 longterm kernel failed and it seems to be a 'drm 
> error'
> 
> Xorg error :
> 
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 14 17:32:59 2025
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> (==) No Layout section.  Using the first Screen section.
> (==) No screen section available. Using defaults.
> (**) |-->Screen "Default Screen Section" (0)
> (**) |   |-->Monitor "<default monitor>"
> (==) No monitor specified for screen "Default Screen Section".
> a default monitor configuration.
> (==) Automatically adding devices
> (==) Automatically enabling devices
> (==) Automatically adding GPU devices
> (==) Automatically binding GPU devices
> (==) Max clients allowed: 256, resource mask: 0x1fffff
> (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
> Entry deleted from font path.
> (==) FontPath set to:
> /usr/share/fonts/X11/misc,
> /usr/share/fonts/X11/100dpi/:unscaled,
> /usr/share/fonts/X11/75dpi/:unscaled,
> /usr/share/fonts/X11/Type1,
> /usr/share/fonts/X11/100dpi,
> /usr/share/fonts/X11/75dpi,
> built-ins
> (==) ModulePath set to "/usr/lib/xorg/modules"
> (II) The server relies on udev to provide the list of input devices.
> no devices become available, reconfigure udev or disable 
> AutoAddDevices.
> (II) Loader magic: 0x561372a83f00
> (II) Module ABI versions:
> X.Org ANSI C Emulation: 0.4
> X.Org Video Driver: 25.2
> X.Org XInput driver : 24.4
> X.Org Server Extension : 10.0
> (++) using VT number 1
> 
> (II) systemd-logind: took control of session 
> /org/freedesktop/login1/session/c13
> (II) xfree86: Adding drm device (/dev/dri/card1)
> (II) Platform probe for 
> /sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/drm/card1
> (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 14 paused 0
> (EE)
> (EE) Backtrace:
> (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5613729f7f79]
> (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
> [0x7f0dad05b050]
> (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (__nss_database_lookup+0xcd19) 
> [0x7f0dad17m.so.2 (drmGetVe728e67a4]
> (EE) 6: /usr/lib/xorg/Xorg (xf86PlatformDeviceCheckBusID+0x1bb) 
> [0x5613728e6aab]
> (EE) 7: /usr/lib/xorg/Xorg (config_fini+0x19b7) [0x5613728e3a97]
> (EE) 8: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x1b5) 
> [0x5613728e0615]
> (EE) 9: /usr/lib/xorg/Xorg (xf86BusProbe+0x9) [0x5613728b9329]
> (EE) 10: /usr/lib/xorg/Xorg (InitOutput+0x69a) [0x5613728c72ca]
> (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x56137288866e]
> (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
> [0x7f0dad04624a]
> (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
> [0x7f0dad046305]
> (EE) 14: /usr/lib/xorg/Xorg (_start+0x21) [0x561372871b71]
> (EE)
> (EE) Segmentation fault at address 0x0
> (EE)
> server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting
> (EE)
> (EE)
> consult the The X.Org Foundation support
> at http://wiki.x.org
> for help.
> (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
> additional information.
> (EE)
> (EE) Server terminated with error (1). Closing log file.
> 
> Kernel trace :
> 
> ------------[ cut here ]------------
> BUG: the value to copy was not set!
> WARNING: CPU: 10 PID: 6240 at drivers/gpu/drm/drm_ioctl.c:478 
> drm_copy_field+0xa2/0xb0 [drm]
> Modules linked in: xt_CHECKSUM(E) xt_MASQUERADE(E) xt_conntrack(E) 
> ipt_REJECT(E) nf_reject_ipv4(E) xt_tcpudp(E) nft_compat(E) 
> nft_chain_nat(E) nf_tables(E) nls_utf8(E) nfnetlink(E) 
> cpufreq_userspace(E) cifs(E) l2tp_ppp(E) cifs_arc4(E) l2tp_netlink(E) 
> cpufreq_ondemand(E) rdma_cm(E) l2tp_core(E) iw_cm(E) ip6_udp_tunnel(E) 
> udp_tunnel(E) cpufreq_conservative(E) ib_cm(E) pppox(E) ppp_generic(E) 
> slhc(E) ib_core(E) cifs_md4(E) dns_resolver(E) cpufreq_powersave(E) 
> xfrm_user(E) xfrm_algo(E) scsi_transport_iscsi(E) nvme_fabrics(E) 
> team_mode_loadbalance(E) 8021q(E) garp(E) mrp(E) team(E) bridge(E) 
> stp(E) llc(E) qrtr(E) openvswitch(E) nsh(E) nf_conncount(E) nf_nat(E) 
> nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) cmac(E) 
> algif_hash(E) algif_skcipher(E) af_alg(E) bnep(E) binfmt_misc(E) 
> nls_ascii(E) nls_cp437(E) vfat(E) fat(E) ext4(E) mbcache(E) jbd2(E) 
> intel_rapl_msr(E) intel_rapl_common(E) nvidia_drm(POE) 
> snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E)
> nvidia_modeset(POE) intel_uncore_frequency(E) 
> intel_uncore_frequency_common(E) sb_edac(E) btusb(E) snd_hda_intel(E) 
> btrtl(E) snd_usb_audio(E) x86_pkg_temp_thermal(E) btbcm(E) 
> snd_intel_dspcfg(E) snd_intel_sdw_acpi(E) intel_powerclamp(E) 
> snd_usbmidi_lib(E) btintel(E) snd_rawmidi(E) coretemp(E) btmtk(E) 
> snd_seq_device(E) snd_hda_codec(E) nvidia(POE) eeepc_wmi(E) 
> snd_hda_core(E) mc(E) snd_pcsp(E) snd_hwdep(E) rapl(E) asus_wmi(E) 
> ipmi_ssif(E) battery(E) iTCO_wdt(E) bluetooth(E) intel_cstate(E) 
> snd_pcm(E) sparse_keymap(E) ledtrig_audio(E) snd_timer(E) 
> intel_pmc_bxt(E) acpi_ipmi(E) platform_profile(E) intel_uncore(E) 
> crc16(E) wmi_bmof(E) rfkill(E) mei_me(E) iTCO_vendor_support(E) 
> ipmi_si(E) snd(E) watchdog(E) mei(E) video(E) soundcore(E) 
> ipmi_devintf(E) ipmi_msghandler(E) joydev(E) evdev(E) sg(E) msr(E) 
> parport_pc(E) ppdev(E) nfsd(E) lp(E) parport(E) auth_rpcgss(E) 
> nfs_acl(E) lockd(E) grace(E) loop(E) efi_pstore(E) configfs(E) 
> sunrpc(E) ip_tables(E) x_tables(E) autofs4(E)
> btrfs(E) blake2b_generic(E) zstd_compress(E) efivarfs(E) raid10(E) 
> sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_plantronics(E) 
> hid_logitech_dj(E) hid_generic(E) uas(E) usbhid(E) hid(E) 
> usb_storage(E) raid456(E) async_raid6_recov(E) async_memcpy(E) 
> async_pq(E) async_xor(E) async_tx(E) xor(E) raid1(E) raid0(E) 
> raid6_pq(E) dm_mod(E) crc32c_intel(E) md_mod(E) sd_mod(E) ast(E) 
> drm_vram_helper(E) drm_ttm_helper(E) ghash_clmulni_intel(E) ttm(E) 
> sha512_ssse3(E) sha256_ssse3(E) drm_kms_helper(E) sha1_ssse3(E) ahci(E) 
> libahci(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) 
> aesni_intel(E) nvme(E) mxm_wmi(E) igb(E) libata(E) crypto_simd(E) 
> i2c_i801(E) cryptd(E) drm(E) dca(E) i2c_smbus(E) lpc_ich(E) usbcore(E) 
> scsi_mod(E) i2c_algo_bit(E) nvme_core(E) t10_pi(E) usb_common(E) 
> scsi_common(E) i40e(E) wmi(E) button(E)
> CPU: 10 PID: 6240 Comm: Xorg Tainted: P           OE      6.1.128-amd64 
> #0
> Hardware name: ASUS All Series/X99-WS/IPMI, BIOS 4001 05/28/2019
> RIP: 0010:drm_copy_field+0xa2/0xb0 [drm]
> Code: 00 00 74 13 49 c7 45 00 00 00 00 00 eb e0 0f 0b b8 f2 ff ff ff eb 
> d9 48 c7 c7 70 cb 17 c1 c6 05 43 17 07 00 01 e8 2e 09 57 dd <0f> 0b eb 
> d6 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 0f 1f 44 00
> RSP: 0018:ffffbd9941b0fba8 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: ffffbd9941b0fc60 RCX: 0000000000000027
> RDX: ffff9ec3bf6a13a8 RSI: 0000000000000001 RDI: ffff9ec3bf6a13a0
> RBP: ffff9e8487476800 R08: 0000000000000000 R09: ffffbd9941b0fa20
> R10: 0000000000000003 R11: ffff9ec3bff15ee8 R12: ffffffffc1132570
> R13: ffffbd9941b0fc80 R14: ffff9e85881d7200 R15: 0000000000000040
> FS:  00007f59dd209ac0(0000) GS:ffff9ec3bf680000(0000) 
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000056272a2123d0 CR3: 000000010c396005 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> ? __warn+0x81/0xd0
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? report_bug+0xe6/0x150
> ? handle_bug+0x41/0x70
> ? exc_invalid_op+0x17/0x70
> ? asm_exc_invalid_op+0x1a/0x20
> ? drm_ioctl_flags+0x50/0x50 [drm]
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? drm_ioctl_flags+0x50/0x50 [drm]
> drm_version+0x73/0xa0 [drm]
> drm_ioctl_kernel+0xcd/0x170 [drm]
> drm_ioctl+0x233/0x410 [drm]
> ? drm_ioctl_flags+0x50/0x50 [drm]
> __x64_sys_ioctl+0x94/0xd0
> do_syscall_64+0x59/0xb0
> ? vfs_write+0x2b1/0x3f0
> ? vfs_write+0x2b1/0x3f0
> ? ksys_write+0x6f/0xf0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? __x64_sys_fcntl+0x94/0xc0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> RIP: 0033:0x7f59dd31ccdb
> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 
> 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 
> 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> RSP: 002b:00007fff22f5d440 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 000056272a211f10 RCX: 00007f59dd31ccdb
> RDX: 000056272a211f10 RSI: 00000000c0406400 RDI: 000000000000000e
> RBP: 000056272a211f10 R08: 00007f59dd3f1cc0 R09: 0000000000000070
> R10: 00007f59dd236378 R11: 0000000000000246 R12: 00000000c0406400
> R13: 000000000000000e R14: 000000000000000e R15: 000056272a211510
> </TASK>
> ---[ end trace 0000000000000000 ]---
> 
> Maybe my Xorg is too recent (but I hope not) as I don't want to 
> downgrade Xorg (nor reinstall an older debian version) so I will try 
> another kernel version...
> 6.1.128 was build by me and maybe the 'make olddefconfig' from mainline 
> to 6.1.128 lost too many options (for ex 
> device-drivers/graphic-support>drm does not exist in menuconfig and I 
> found AST module directly in device-drivers/graphic-support ...)
> 6.1.124 exist prepackaged by Debian so it .config should be more 
> generic so I will test it
> 
> Thanks again for help,
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-14 16:01, Nicolas Baranger a écrit :
> 
> Hi Thomas
> 
> Thanks again for help
> 
> 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.
> Ok, I will try to find a working kernel and to git bisect to find the 
> commit which introduce the problem.
> I will start with longterm 6.1.128
> 
> Kind regards
> Nicolas
> 
> Le 2025-02-14 13:36, Thomas Zimmermann a écrit :
> 
> 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,

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

[Thomas Zimmermann]

Hi

Am 14.02.25 um 18:52 schrieb Nicolas Baranger:
> Hi Thomas, Jocelyn
>
> Same error with linux-6.1.124 debian package ...
> It's reported in log as a drm bug by kernel:
>
> ------------[ cut here ]------------
> BUG: the value to copy was not set!
> WARNING: CPU: 13 PID: 6163 at drivers/gpu/drm/drm_ioctl.c:478 
> drm_copy_field+0xa2/0xb0 [drm]

All these errors don't look as if they are directly related to ast. It's 
something in the DRM core or Xorg.

>
> This server had already work with Linux 6.1 in the past so I don't 
> know what to think...
> The last linux-6.1 version I'm sure that had work on this server was 
> 6.1.85 (according to my post here 
> https://bugzilla.kernel.org/show_bug.cgi?id=219480#c3)

That's btrfs AFAICS; so not related to ast.

What happens on older kernels, such as 6.0, 5.*, etc. I'd be interested 
in finding an old kernel with acceptable ast performance. That we can 
compare the code or further bisect.

Best regards
Thomas

>
> Maybe I should install a new Debian system on a usb stick for doing tests
>
> Going back here with next results
> Thanks again for help
>
>
> Kind regards,
> Nicolas Baranger
>
>
>
> Le 2025-02-14 18:03, Nicolas Baranger a écrit :
>
>> Hi Thomas, Jocelyn
>>
>> Starting with 6.1.128 longterm kernel failed and it seems to be a 
>> 'drm error'
>>
>> Xorg error :
>>
>> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 14 17:32:59 2025
>> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>> (==) No Layout section.  Using the first Screen section.
>> (==) No screen section available. Using defaults.
>> (**) |-->Screen "Default Screen Section" (0)
>> (**) |   |-->Monitor "<default monitor>"
>> (==) No monitor specified for screen "Default Screen Section".
>> a default monitor configuration.
>> (==) Automatically adding devices
>> (==) Automatically enabling devices
>> (==) Automatically adding GPU devices
>> (==) Automatically binding GPU devices
>> (==) Max clients allowed: 256, resource mask: 0x1fffff
>> (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
>> Entry deleted from font path.
>> (==) FontPath set to:
>> /usr/share/fonts/X11/misc,
>> /usr/share/fonts/X11/100dpi/:unscaled,
>> /usr/share/fonts/X11/75dpi/:unscaled,
>> /usr/share/fonts/X11/Type1,
>> /usr/share/fonts/X11/100dpi,
>> /usr/share/fonts/X11/75dpi,
>> built-ins
>> (==) ModulePath set to "/usr/lib/xorg/modules"
>> (II) The server relies on udev to provide the list of input devices.
>> no devices become available, reconfigure udev or disable AutoAddDevices.
>> (II) Loader magic: 0x561372a83f00
>> (II) Module ABI versions:
>> X.Org ANSI C Emulation: 0.4
>> X.Org Video Driver: 25.2
>> X.Org XInput driver : 24.4
>> X.Org Server Extension : 10.0
>> (++) using VT number 1
>>
>> (II) systemd-logind: took control of session 
>> /org/freedesktop/login1/session/c13
>> (II) xfree86: Adding drm device (/dev/dri/card1)
>> (II) Platform probe for 
>> /sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/drm/card1
>> (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 14 paused 0
>> (EE)
>> (EE) Backtrace:
>> (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5613729f7f79]
>> (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
>> [0x7f0dad05b050]
>> (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 
>> (__nss_database_lookup+0xcd19) [0x7f0dad17m.so.2 (drmGetVe728e67a4]
>> (EE) 6: /usr/lib/xorg/Xorg (xf86PlatformDeviceCheckBusID+0x1bb) 
>> [0x5613728e6aab]
>> (EE) 7: /usr/lib/xorg/Xorg (config_fini+0x19b7) [0x5613728e3a97]
>> (EE) 8: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x1b5) 
>> [0x5613728e0615]
>> (EE) 9: /usr/lib/xorg/Xorg (xf86BusProbe+0x9) [0x5613728b9329]
>> (EE) 10: /usr/lib/xorg/Xorg (InitOutput+0x69a) [0x5613728c72ca]
>> (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x56137288866e]
>> (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
>> [0x7f0dad04624a]
>> (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
>> [0x7f0dad046305]
>> (EE) 14: /usr/lib/xorg/Xorg (_start+0x21) [0x561372871b71]
>> (EE)
>> (EE) Segmentation fault at address 0x0
>> (EE)
>> server error:
>> (EE) Caught signal 11 (Segmentation fault). Server aborting
>> (EE)
>> (EE)
>> consult the The X.Org Foundation support
>> at http://wiki.x.org
>> for help.
>> (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
>> additional information.
>> (EE)
>> (EE) Server terminated with error (1). Closing log file.
>>
>> Kernel trace :
>>
>> ------------[ cut here ]------------
>> BUG: the value to copy was not set!
>> WARNING: CPU: 10 PID: 6240 at drivers/gpu/drm/drm_ioctl.c:478 
>> drm_copy_field+0xa2/0xb0 [drm]
>> Modules linked in: xt_CHECKSUM(E) xt_MASQUERADE(E) xt_conntrack(E) 
>> ipt_REJECT(E) nf_reject_ipv4(E) xt_tcpudp(E) nft_compat(E) 
>> nft_chain_nat(E) nf_tables(E) nls_utf8(E) nfnetlink(E) 
>> cpufreq_userspace(E) cifs(E) l2tp_ppp(E) cifs_arc4(E) l2tp_netlink(E) 
>> cpufreq_ondemand(E) rdma_cm(E) l2tp_core(E) iw_cm(E) 
>> ip6_udp_tunnel(E) udp_tunnel(E) cpufreq_conservative(E) ib_cm(E) 
>> pppox(E) ppp_generic(E) slhc(E) ib_core(E) cifs_md4(E) 
>> dns_resolver(E) cpufreq_powersave(E) xfrm_user(E) xfrm_algo(E) 
>> scsi_transport_iscsi(E) nvme_fabrics(E) team_mode_loadbalance(E) 
>> 8021q(E) garp(E) mrp(E) team(E) bridge(E) stp(E) llc(E) qrtr(E) 
>> openvswitch(E) nsh(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) 
>> nf_defrag_ipv6(E) nf_defrag_ipv4(E) cmac(E) algif_hash(E) 
>> algif_skcipher(E) af_alg(E) bnep(E) binfmt_misc(E) nls_ascii(E) 
>> nls_cp437(E) vfat(E) fat(E) ext4(E) mbcache(E) jbd2(E) 
>> intel_rapl_msr(E) intel_rapl_common(E) nvidia_drm(POE) 
>> snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E)
>> nvidia_modeset(POE) intel_uncore_frequency(E) 
>> intel_uncore_frequency_common(E) sb_edac(E) btusb(E) snd_hda_intel(E) 
>> btrtl(E) snd_usb_audio(E) x86_pkg_temp_thermal(E) btbcm(E) 
>> snd_intel_dspcfg(E) snd_intel_sdw_acpi(E) intel_powerclamp(E) 
>> snd_usbmidi_lib(E) btintel(E) snd_rawmidi(E) coretemp(E) btmtk(E) 
>> snd_seq_device(E) snd_hda_codec(E) nvidia(POE) eeepc_wmi(E) 
>> snd_hda_core(E) mc(E) snd_pcsp(E) snd_hwdep(E) rapl(E) asus_wmi(E) 
>> ipmi_ssif(E) battery(E) iTCO_wdt(E) bluetooth(E) intel_cstate(E) 
>> snd_pcm(E) sparse_keymap(E) ledtrig_audio(E) snd_timer(E) 
>> intel_pmc_bxt(E) acpi_ipmi(E) platform_profile(E) intel_uncore(E) 
>> crc16(E) wmi_bmof(E) rfkill(E) mei_me(E) iTCO_vendor_support(E) 
>> ipmi_si(E) snd(E) watchdog(E) mei(E) video(E) soundcore(E) 
>> ipmi_devintf(E) ipmi_msghandler(E) joydev(E) evdev(E) sg(E) msr(E) 
>> parport_pc(E) ppdev(E) nfsd(E) lp(E) parport(E) auth_rpcgss(E) 
>> nfs_acl(E) lockd(E) grace(E) loop(E) efi_pstore(E) configfs(E) 
>> sunrpc(E) ip_tables(E) x_tables(E) autofs4(E)
>> btrfs(E) blake2b_generic(E) zstd_compress(E) efivarfs(E) raid10(E) 
>> sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_plantronics(E) 
>> hid_logitech_dj(E) hid_generic(E) uas(E) usbhid(E) hid(E) 
>> usb_storage(E) raid456(E) async_raid6_recov(E) async_memcpy(E) 
>> async_pq(E) async_xor(E) async_tx(E) xor(E) raid1(E) raid0(E) 
>> raid6_pq(E) dm_mod(E) crc32c_intel(E) md_mod(E) sd_mod(E) ast(E) 
>> drm_vram_helper(E) drm_ttm_helper(E) ghash_clmulni_intel(E) ttm(E) 
>> sha512_ssse3(E) sha256_ssse3(E) drm_kms_helper(E) sha1_ssse3(E) 
>> ahci(E) libahci(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) 
>> aesni_intel(E) nvme(E) mxm_wmi(E) igb(E) libata(E) crypto_simd(E) 
>> i2c_i801(E) cryptd(E) drm(E) dca(E) i2c_smbus(E) lpc_ich(E) 
>> usbcore(E) scsi_mod(E) i2c_algo_bit(E) nvme_core(E) t10_pi(E) 
>> usb_common(E) scsi_common(E) i40e(E) wmi(E) button(E)
>> CPU: 10 PID: 6240 Comm: Xorg Tainted: P           OE 6.1.128-amd64 #0
>> Hardware name: ASUS All Series/X99-WS/IPMI, BIOS 4001 05/28/2019
>> RIP: 0010:drm_copy_field+0xa2/0xb0 [drm]
>> Code: 00 00 74 13 49 c7 45 00 00 00 00 00 eb e0 0f 0b b8 f2 ff ff ff 
>> eb d9 48 c7 c7 70 cb 17 c1 c6 05 43 17 07 00 01 e8 2e 09 57 dd <0f> 
>> 0b eb d6 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 0f 1f 44 00
>> RSP: 0018:ffffbd9941b0fba8 EFLAGS: 00010286
>> RAX: 0000000000000000 RBX: ffffbd9941b0fc60 RCX: 0000000000000027
>> RDX: ffff9ec3bf6a13a8 RSI: 0000000000000001 RDI: ffff9ec3bf6a13a0
>> RBP: ffff9e8487476800 R08: 0000000000000000 R09: ffffbd9941b0fa20
>> R10: 0000000000000003 R11: ffff9ec3bff15ee8 R12: ffffffffc1132570
>> R13: ffffbd9941b0fc80 R14: ffff9e85881d7200 R15: 0000000000000040
>> FS:  00007f59dd209ac0(0000) GS:ffff9ec3bf680000(0000) 
>> knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 000056272a2123d0 CR3: 000000010c396005 CR4: 00000000003706e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>> <TASK>
>> ? __warn+0x81/0xd0
>> ? drm_copy_field+0xa2/0xb0 [drm]
>> ? report_bug+0xe6/0x150
>> ? handle_bug+0x41/0x70
>> ? exc_invalid_op+0x17/0x70
>> ? asm_exc_invalid_op+0x1a/0x20
>> ? drm_ioctl_flags+0x50/0x50 [drm]
>> ? drm_copy_field+0xa2/0xb0 [drm]
>> ? drm_copy_field+0xa2/0xb0 [drm]
>> ? drm_ioctl_flags+0x50/0x50 [drm]
>> drm_version+0x73/0xa0 [drm]
>> drm_ioctl_kernel+0xcd/0x170 [drm]
>> drm_ioctl+0x233/0x410 [drm]
>> ? drm_ioctl_flags+0x50/0x50 [drm]
>> __x64_sys_ioctl+0x94/0xd0
>> do_syscall_64+0x59/0xb0
>> ? vfs_write+0x2b1/0x3f0
>> ? vfs_write+0x2b1/0x3f0
>> ? ksys_write+0x6f/0xf0
>> ? exit_to_user_mode_prepare+0x40/0x1e0
>> ? syscall_exit_to_user_mode+0x22/0x40
>> ? do_syscall_64+0x65/0xb0
>> ? __x64_sys_fcntl+0x94/0xc0
>> ? exit_to_user_mode_prepare+0x40/0x1e0
>> ? syscall_exit_to_user_mode+0x22/0x40
>> ? do_syscall_64+0x65/0xb0
>> ? syscall_exit_to_user_mode+0x22/0x40
>> ? do_syscall_64+0x65/0xb0
>> ? exit_to_user_mode_prepare+0x40/0x1e0
>> entry_SYSCALL_64_after_hwframe+0x6e/0xd8
>> RIP: 0033:0x7f59dd31ccdb
>> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 
>> 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> 
>> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
>> RSP: 002b:00007fff22f5d440 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
>> RAX: ffffffffffffffda RBX: 000056272a211f10 RCX: 00007f59dd31ccdb
>> RDX: 000056272a211f10 RSI: 00000000c0406400 RDI: 000000000000000e
>> RBP: 000056272a211f10 R08: 00007f59dd3f1cc0 R09: 0000000000000070
>> R10: 00007f59dd236378 R11: 0000000000000246 R12: 00000000c0406400
>> R13: 000000000000000e R14: 000000000000000e R15: 000056272a211510
>> </TASK>
>> ---[ end trace 0000000000000000 ]---
>>
>> Maybe my Xorg is too recent (but I hope not) as I don't want to 
>> downgrade Xorg (nor reinstall an older debian version) so I will try 
>> another kernel version...
>> 6.1.128 was build by me and maybe the 'make olddefconfig' from 
>> mainline to 6.1.128 lost too many options (for ex 
>> device-drivers/graphic-support>drm does not exist in menuconfig and I 
>> found AST module directly in device-drivers/graphic-support ...)
>> 6.1.124 exist prepackaged by Debian so it .config should be more 
>> generic so I will test it
>>
>> Thanks again for help,
>>
>> Kind regards
>> Nicolas Baranger
>>
>> Le 2025-02-14 16:01, Nicolas Baranger a écrit :
>>
>> Hi Thomas
>>
>> Thanks again for help
>>
>> 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.
>> Ok, I will try to find a working kernel and to git bisect to find the 
>> commit which introduce the problem.
>> I will start with longterm 6.1.128
>>
>> Kind regards
>> Nicolas
>>
>> Le 2025-02-14 13:36, Thomas Zimmermann a écrit :
>>
>> 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)

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

[Nicolas Baranger]

Dear Thomas

Thanks for answer and help

> All these errors don't look as if they are directly related to ast. 
> It's something in the DRM core or Xorg.

Yes it's Xorg DRM issue

> That's btrfs AFAICS; so not related to ast

That was not BTRFS, it was ACPI / PCIE (sure not related to ast) but as 
I report this bug and bissect on the same hardware, it proof that Linux 
6.1.85 already work on this particular hardware

The actual install is working very fine on mainline so I don't want to 
break it (and Xorg) to make Linux 6.1 work on it.
I did installed a test system on another drive of this server during the 
week-end so now I don't care to break Xorg or whatever on this new 
install and I can continue bissection.

Kind regards
Nicolas Baranger

Le 2025-02-17 09:11, Thomas Zimmermann a écrit :

> Hi
> 
> Am 14.02.25 um 18:52 schrieb Nicolas Baranger:
> 
>> Hi Thomas, Jocelyn
>> 
>> Same error with linux-6.1.124 debian package ...
>> It's reported in log as a drm bug by kernel:
>> 
>> ------------[ cut here ]------------
>> BUG: the value to copy was not set!
>> WARNING: CPU: 13 PID: 6163 at drivers/gpu/drm/drm_ioctl.c:478 
>> drm_copy_field+0xa2/0xb0 [drm]
> 
> All these errors don't look as if they are directly related to ast. 
> It's something in the DRM core or Xorg.
> 
>> This server had already work with Linux 6.1 in the past so I don't 
>> know what to think...
>> The last linux-6.1 version I'm sure that had work on this server was 
>> 6.1.85 (according to my post here 
>> https://bugzilla.kernel.org/show_bug.cgi?id=219480#c3)
> 
> That's btrfs AFAICS; so not related to ast.
> 
> What happens on older kernels, such as 6.0, 5.*, etc. I'd be interested 
> in finding an old kernel with acceptable ast performance. That we can 
> compare the code or further bisect.
> 
> Best regards
> Thomas
> 
> Maybe I should install a new Debian system on a usb stick for doing 
> tests
> 
> Going back here with next results
> Thanks again for help
> 
> Kind regards,
> Nicolas Baranger
> 
> Le 2025-02-14 18:03, Nicolas Baranger a écrit :
> 
> Hi Thomas, Jocelyn
> 
> Starting with 6.1.128 longterm kernel failed and it seems to be a 'drm 
> error'
> 
> Xorg error :
> 
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 14 17:32:59 2025
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> (==) No Layout section.  Using the first Screen section.
> (==) No screen section available. Using defaults.
> (**) |-->Screen "Default Screen Section" (0)
> (**) |   |-->Monitor "<default monitor>"
> (==) No monitor specified for screen "Default Screen Section".
> a default monitor configuration.
> (==) Automatically adding devices
> (==) Automatically enabling devices
> (==) Automatically adding GPU devices
> (==) Automatically binding GPU devices
> (==) Max clients allowed: 256, resource mask: 0x1fffff
> (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
> Entry deleted from font path.
> (==) FontPath set to:
> /usr/share/fonts/X11/misc,
> /usr/share/fonts/X11/100dpi/:unscaled,
> /usr/share/fonts/X11/75dpi/:unscaled,
> /usr/share/fonts/X11/Type1,
> /usr/share/fonts/X11/100dpi,
> /usr/share/fonts/X11/75dpi,
> built-ins
> (==) ModulePath set to "/usr/lib/xorg/modules"
> (II) The server relies on udev to provide the list of input devices.
> no devices become available, reconfigure udev or disable 
> AutoAddDevices.
> (II) Loader magic: 0x561372a83f00
> (II) Module ABI versions:
> X.Org ANSI C Emulation: 0.4
> X.Org Video Driver: 25.2
> X.Org XInput driver : 24.4
> X.Org Server Extension : 10.0
> (++) using VT number 1
> 
> (II) systemd-logind: took control of session 
> /org/freedesktop/login1/session/c13
> (II) xfree86: Adding drm device (/dev/dri/card1)
> (II) Platform probe for 
> /sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/drm/card1
> (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 14 paused 0
> (EE)
> (EE) Backtrace:
> (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5613729f7f79]
> (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
> [0x7f0dad05b050]
> (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (__nss_database_lookup+0xcd19) 
> [0x7f0dad17m.so.2 (drmGetVe728e67a4]
> (EE) 6: /usr/lib/xorg/Xorg (xf86PlatformDeviceCheckBusID+0x1bb) 
> [0x5613728e6aab]
> (EE) 7: /usr/lib/xorg/Xorg (config_fini+0x19b7) [0x5613728e3a97]
> (EE) 8: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x1b5) 
> [0x5613728e0615]
> (EE) 9: /usr/lib/xorg/Xorg (xf86BusProbe+0x9) [0x5613728b9329]
> (EE) 10: /usr/lib/xorg/Xorg (InitOutput+0x69a) [0x5613728c72ca]
> (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x56137288866e]
> (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
> [0x7f0dad04624a]
> (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
> [0x7f0dad046305]
> (EE) 14: /usr/lib/xorg/Xorg (_start+0x21) [0x561372871b71]
> (EE)
> (EE) Segmentation fault at address 0x0
> (EE)
> server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting
> (EE)
> (EE)
> consult the The X.Org Foundation support
> at http://wiki.x.org
> for help.
> (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
> additional information.
> (EE)
> (EE) Server terminated with error (1). Closing log file.
> 
> Kernel trace :
> 
> ------------[ cut here ]------------
> BUG: the value to copy was not set!
> WARNING: CPU: 10 PID: 6240 at drivers/gpu/drm/drm_ioctl.c:478 
> drm_copy_field+0xa2/0xb0 [drm]
> Modules linked in: xt_CHECKSUM(E) xt_MASQUERADE(E) xt_conntrack(E) 
> ipt_REJECT(E) nf_reject_ipv4(E) xt_tcpudp(E) nft_compat(E) 
> nft_chain_nat(E) nf_tables(E) nls_utf8(E) nfnetlink(E) 
> cpufreq_userspace(E) cifs(E) l2tp_ppp(E) cifs_arc4(E) l2tp_netlink(E) 
> cpufreq_ondemand(E) rdma_cm(E) l2tp_core(E) iw_cm(E) ip6_udp_tunnel(E) 
> udp_tunnel(E) cpufreq_conservative(E) ib_cm(E) pppox(E) ppp_generic(E) 
> slhc(E) ib_core(E) cifs_md4(E) dns_resolver(E) cpufreq_powersave(E) 
> xfrm_user(E) xfrm_algo(E) scsi_transport_iscsi(E) nvme_fabrics(E) 
> team_mode_loadbalance(E) 8021q(E) garp(E) mrp(E) team(E) bridge(E) 
> stp(E) llc(E) qrtr(E) openvswitch(E) nsh(E) nf_conncount(E) nf_nat(E) 
> nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) cmac(E) 
> algif_hash(E) algif_skcipher(E) af_alg(E) bnep(E) binfmt_misc(E) 
> nls_ascii(E) nls_cp437(E) vfat(E) fat(E) ext4(E) mbcache(E) jbd2(E) 
> intel_rapl_msr(E) intel_rapl_common(E) nvidia_drm(POE) 
> snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E)
> nvidia_modeset(POE) intel_uncore_frequency(E) 
> intel_uncore_frequency_common(E) sb_edac(E) btusb(E) snd_hda_intel(E) 
> btrtl(E) snd_usb_audio(E) x86_pkg_temp_thermal(E) btbcm(E) 
> snd_intel_dspcfg(E) snd_intel_sdw_acpi(E) intel_powerclamp(E) 
> snd_usbmidi_lib(E) btintel(E) snd_rawmidi(E) coretemp(E) btmtk(E) 
> snd_seq_device(E) snd_hda_codec(E) nvidia(POE) eeepc_wmi(E) 
> snd_hda_core(E) mc(E) snd_pcsp(E) snd_hwdep(E) rapl(E) asus_wmi(E) 
> ipmi_ssif(E) battery(E) iTCO_wdt(E) bluetooth(E) intel_cstate(E) 
> snd_pcm(E) sparse_keymap(E) ledtrig_audio(E) snd_timer(E) 
> intel_pmc_bxt(E) acpi_ipmi(E) platform_profile(E) intel_uncore(E) 
> crc16(E) wmi_bmof(E) rfkill(E) mei_me(E) iTCO_vendor_support(E) 
> ipmi_si(E) snd(E) watchdog(E) mei(E) video(E) soundcore(E) 
> ipmi_devintf(E) ipmi_msghandler(E) joydev(E) evdev(E) sg(E) msr(E) 
> parport_pc(E) ppdev(E) nfsd(E) lp(E) parport(E) auth_rpcgss(E) 
> nfs_acl(E) lockd(E) grace(E) loop(E) efi_pstore(E) configfs(E) 
> sunrpc(E) ip_tables(E) x_tables(E) autofs4(E)
> btrfs(E) blake2b_generic(E) zstd_compress(E) efivarfs(E) raid10(E) 
> sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_plantronics(E) 
> hid_logitech_dj(E) hid_generic(E) uas(E) usbhid(E) hid(E) 
> usb_storage(E) raid456(E) async_raid6_recov(E) async_memcpy(E) 
> async_pq(E) async_xor(E) async_tx(E) xor(E) raid1(E) raid0(E) 
> raid6_pq(E) dm_mod(E) crc32c_intel(E) md_mod(E) sd_mod(E) ast(E) 
> drm_vram_helper(E) drm_ttm_helper(E) ghash_clmulni_intel(E) ttm(E) 
> sha512_ssse3(E) sha256_ssse3(E) drm_kms_helper(E) sha1_ssse3(E) ahci(E) 
> libahci(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) 
> aesni_intel(E) nvme(E) mxm_wmi(E) igb(E) libata(E) crypto_simd(E) 
> i2c_i801(E) cryptd(E) drm(E) dca(E) i2c_smbus(E) lpc_ich(E) usbcore(E) 
> scsi_mod(E) i2c_algo_bit(E) nvme_core(E) t10_pi(E) usb_common(E) 
> scsi_common(E) i40e(E) wmi(E) button(E)
> CPU: 10 PID: 6240 Comm: Xorg Tainted: P           OE 6.1.128-amd64 #0
> Hardware name: ASUS All Series/X99-WS/IPMI, BIOS 4001 05/28/2019
> RIP: 0010:drm_copy_field+0xa2/0xb0 [drm]
> Code: 00 00 74 13 49 c7 45 00 00 00 00 00 eb e0 0f 0b b8 f2 ff ff ff eb 
> d9 48 c7 c7 70 cb 17 c1 c6 05 43 17 07 00 01 e8 2e 09 57 dd <0f> 0b eb 
> d6 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 0f 1f 44 00
> RSP: 0018:ffffbd9941b0fba8 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: ffffbd9941b0fc60 RCX: 0000000000000027
> RDX: ffff9ec3bf6a13a8 RSI: 0000000000000001 RDI: ffff9ec3bf6a13a0
> RBP: ffff9e8487476800 R08: 0000000000000000 R09: ffffbd9941b0fa20
> R10: 0000000000000003 R11: ffff9ec3bff15ee8 R12: ffffffffc1132570
> R13: ffffbd9941b0fc80 R14: ffff9e85881d7200 R15: 0000000000000040
> FS:  00007f59dd209ac0(0000) GS:ffff9ec3bf680000(0000) 
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000056272a2123d0 CR3: 000000010c396005 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> ? __warn+0x81/0xd0
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? report_bug+0xe6/0x150
> ? handle_bug+0x41/0x70
> ? exc_invalid_op+0x17/0x70
> ? asm_exc_invalid_op+0x1a/0x20
> ? drm_ioctl_flags+0x50/0x50 [drm]
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? drm_ioctl_flags+0x50/0x50 [drm]
> drm_version+0x73/0xa0 [drm]
> drm_ioctl_kernel+0xcd/0x170 [drm]
> drm_ioctl+0x233/0x410 [drm]
> ? drm_ioctl_flags+0x50/0x50 [drm]
> __x64_sys_ioctl+0x94/0xd0
> do_syscall_64+0x59/0xb0
> ? vfs_write+0x2b1/0x3f0
> ? vfs_write+0x2b1/0x3f0
> ? ksys_write+0x6f/0xf0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? __x64_sys_fcntl+0x94/0xc0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> RIP: 0033:0x7f59dd31ccdb
> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 
> 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 
> 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> RSP: 002b:00007fff22f5d440 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 000056272a211f10 RCX: 00007f59dd31ccdb
> RDX: 000056272a211f10 RSI: 00000000c0406400 RDI: 000000000000000e
> RBP: 000056272a211f10 R08: 00007f59dd3f1cc0 R09: 0000000000000070
> R10: 00007f59dd236378 R11: 0000000000000246 R12: 00000000c0406400
> R13: 000000000000000e R14: 000000000000000e R15: 000056272a211510
> </TASK>
> ---[ end trace 0000000000000000 ]---
> 
> Maybe my Xorg is too recent (but I hope not) as I don't want to 
> downgrade Xorg (nor reinstall an older debian version) so I will try 
> another kernel version...
> 6.1.128 was build by me and maybe the 'make olddefconfig' from mainline 
> to 6.1.128 lost too many options (for ex 
> device-drivers/graphic-support>drm does not exist in menuconfig and I 
> found AST module directly in device-drivers/graphic-support ...)
> 6.1.124 exist prepackaged by Debian so it .config should be more 
> generic so I will test it
> 
> Thanks again for help,
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-14 16:01, Nicolas Baranger a écrit :
> 
> Hi Thomas
> 
> Thanks again for help
> 
> 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.
> Ok, I will try to find a working kernel and to git bisect to find the 
> commit which introduce the problem.
> I will start with longterm 6.1.128
> 
> Kind regards
> Nicolas
> 
> Le 2025-02-14 13:36, Thomas Zimmermann a écrit :
> 
> 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,

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

[Nicolas Baranger]

Dear Thomas, Jocelyn

Sorry for my late answer and thanks again for help

Linux 6.1.128 is working fine out of the box.

I think Jocelyn was true and a first regression was introduce in Linux 
6.2 but I suspect it's not the only one between 6.1.128 and mainline
Please see video here 
https://xba.soartist.net/ast-drm_nba_20250211/vkcube_linux-6.2.1_20250221-0.webm
You can compare with the other video which was already in the online 
directory 
https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm
Please note that lag on 
vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm are due to the 
screen capture tool (which make dirty captures at only 30fps) but don't 
exist in real life
(to avoid lag when the vulkan cube is running at high speed I need a 
tool which can capture screen at 2000fps. Do you know such tool ?)

I suspect it's not the only regression introduced between 6.1.128 and 
mainline, so I'm continuing bisection

Going back here with new results

Kind regards
Nicolas Baranger




Le 2025-02-17 09:37, Nicolas Baranger a écrit :

> Dear Thomas
> 
> Thanks for answer and help
> 
>> All these errors don't look as if they are directly related to ast. 
>> It's something in the DRM core or Xorg.
> 
> Yes it's Xorg DRM issue
> 
>> That's btrfs AFAICS; so not related to ast
> 
> That was not BTRFS, it was ACPI / PCIE (sure not related to ast) but as 
> I report this bug and bissect on the same hardware, it proof that Linux 
> 6.1.85 already work on this particular hardware
> 
> The actual install is working very fine on mainline so I don't want to 
> break it (and Xorg) to make Linux 6.1 work on it.
> I did installed a test system on another drive of this server during 
> the week-end so now I don't care to break Xorg or whatever on this new 
> install and I can continue bissection.
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-17 09:11, Thomas Zimmermann a écrit :
> 
> Hi
> 
> Am 14.02.25 um 18:52 schrieb Nicolas Baranger:
> 
> Hi Thomas, Jocelyn
> 
> Same error with linux-6.1.124 debian package ...
> It's reported in log as a drm bug by kernel:
> 
> ------------[ cut here ]------------
> BUG: the value to copy was not set!
> WARNING: CPU: 13 PID: 6163 at drivers/gpu/drm/drm_ioctl.c:478 
> drm_copy_field+0xa2/0xb0 [drm]
> All these errors don't look as if they are directly related to ast. 
> It's something in the DRM core or Xorg.
> 
> This server had already work with Linux 6.1 in the past so I don't know 
> what to think...
> The last linux-6.1 version I'm sure that had work on this server was 
> 6.1.85 (according to my post here 
> https://bugzilla.kernel.org/show_bug.cgi?id=219480#c3)
> That's btrfs AFAICS; so not related to ast.
> 
> What happens on older kernels, such as 6.0, 5.*, etc. I'd be interested 
> in finding an old kernel with acceptable ast performance. That we can 
> compare the code or further bisect.
> 
> Best regards
> Thomas
> 
> Maybe I should install a new Debian system on a usb stick for doing 
> tests
> 
> Going back here with next results
> Thanks again for help
> 
> Kind regards,
> Nicolas Baranger
> 
> Le 2025-02-14 18:03, Nicolas Baranger a écrit :
> 
> Hi Thomas, Jocelyn
> 
> Starting with 6.1.128 longterm kernel failed and it seems to be a 'drm 
> error'
> 
> Xorg error :
> 
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 14 17:32:59 2025
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> (==) No Layout section.  Using the first Screen section.
> (==) No screen section available. Using defaults.
> (**) |-->Screen "Default Screen Section" (0)
> (**) |   |-->Monitor "<default monitor>"
> (==) No monitor specified for screen "Default Screen Section".
> a default monitor configuration.
> (==) Automatically adding devices
> (==) Automatically enabling devices
> (==) Automatically adding GPU devices
> (==) Automatically binding GPU devices
> (==) Max clients allowed: 256, resource mask: 0x1fffff
> (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
> Entry deleted from font path.
> (==) FontPath set to:
> /usr/share/fonts/X11/misc,
> /usr/share/fonts/X11/100dpi/:unscaled,
> /usr/share/fonts/X11/75dpi/:unscaled,
> /usr/share/fonts/X11/Type1,
> /usr/share/fonts/X11/100dpi,
> /usr/share/fonts/X11/75dpi,
> built-ins
> (==) ModulePath set to "/usr/lib/xorg/modules"
> (II) The server relies on udev to provide the list of input devices.
> no devices become available, reconfigure udev or disable 
> AutoAddDevices.
> (II) Loader magic: 0x561372a83f00
> (II) Module ABI versions:
> X.Org ANSI C Emulation: 0.4
> X.Org Video Driver: 25.2
> X.Org XInput driver : 24.4
> X.Org Server Extension : 10.0
> (++) using VT number 1
> 
> (II) systemd-logind: took control of session 
> /org/freedesktop/login1/session/c13
> (II) xfree86: Adding drm device (/dev/dri/card1)
> (II) Platform probe for 
> /sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/drm/card1
> (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 14 paused 0
> (EE)
> (EE) Backtrace:
> (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5613729f7f79]
> (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
> [0x7f0dad05b050]
> (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (__nss_database_lookup+0xcd19) 
> [0x7f0dad17m.so.2 (drmGetVe728e67a4]
> (EE) 6: /usr/lib/xorg/Xorg (xf86PlatformDeviceCheckBusID+0x1bb) 
> [0x5613728e6aab]
> (EE) 7: /usr/lib/xorg/Xorg (config_fini+0x19b7) [0x5613728e3a97]
> (EE) 8: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x1b5) 
> [0x5613728e0615]
> (EE) 9: /usr/lib/xorg/Xorg (xf86BusProbe+0x9) [0x5613728b9329]
> (EE) 10: /usr/lib/xorg/Xorg (InitOutput+0x69a) [0x5613728c72ca]
> (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x56137288866e]
> (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
> [0x7f0dad04624a]
> (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
> [0x7f0dad046305]
> (EE) 14: /usr/lib/xorg/Xorg (_start+0x21) [0x561372871b71]
> (EE)
> (EE) Segmentation fault at address 0x0
> (EE)
> server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting
> (EE)
> (EE)
> consult the The X.Org Foundation support
> at http://wiki.x.org
> for help.
> (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
> additional information.
> (EE)
> (EE) Server terminated with error (1). Closing log file.
> 
> Kernel trace :
> 
> ------------[ cut here ]------------
> BUG: the value to copy was not set!
> WARNING: CPU: 10 PID: 6240 at drivers/gpu/drm/drm_ioctl.c:478 
> drm_copy_field+0xa2/0xb0 [drm]
> Modules linked in: xt_CHECKSUM(E) xt_MASQUERADE(E) xt_conntrack(E) 
> ipt_REJECT(E) nf_reject_ipv4(E) xt_tcpudp(E) nft_compat(E) 
> nft_chain_nat(E) nf_tables(E) nls_utf8(E) nfnetlink(E) 
> cpufreq_userspace(E) cifs(E) l2tp_ppp(E) cifs_arc4(E) l2tp_netlink(E) 
> cpufreq_ondemand(E) rdma_cm(E) l2tp_core(E) iw_cm(E) ip6_udp_tunnel(E) 
> udp_tunnel(E) cpufreq_conservative(E) ib_cm(E) pppox(E) ppp_generic(E) 
> slhc(E) ib_core(E) cifs_md4(E) dns_resolver(E) cpufreq_powersave(E) 
> xfrm_user(E) xfrm_algo(E) scsi_transport_iscsi(E) nvme_fabrics(E) 
> team_mode_loadbalance(E) 8021q(E) garp(E) mrp(E) team(E) bridge(E) 
> stp(E) llc(E) qrtr(E) openvswitch(E) nsh(E) nf_conncount(E) nf_nat(E) 
> nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) cmac(E) 
> algif_hash(E) algif_skcipher(E) af_alg(E) bnep(E) binfmt_misc(E) 
> nls_ascii(E) nls_cp437(E) vfat(E) fat(E) ext4(E) mbcache(E) jbd2(E) 
> intel_rapl_msr(E) intel_rapl_common(E) nvidia_drm(POE) 
> snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E)
> nvidia_modeset(POE) intel_uncore_frequency(E) 
> intel_uncore_frequency_common(E) sb_edac(E) btusb(E) snd_hda_intel(E) 
> btrtl(E) snd_usb_audio(E) x86_pkg_temp_thermal(E) btbcm(E) 
> snd_intel_dspcfg(E) snd_intel_sdw_acpi(E) intel_powerclamp(E) 
> snd_usbmidi_lib(E) btintel(E) snd_rawmidi(E) coretemp(E) btmtk(E) 
> snd_seq_device(E) snd_hda_codec(E) nvidia(POE) eeepc_wmi(E) 
> snd_hda_core(E) mc(E) snd_pcsp(E) snd_hwdep(E) rapl(E) asus_wmi(E) 
> ipmi_ssif(E) battery(E) iTCO_wdt(E) bluetooth(E) intel_cstate(E) 
> snd_pcm(E) sparse_keymap(E) ledtrig_audio(E) snd_timer(E) 
> intel_pmc_bxt(E) acpi_ipmi(E) platform_profile(E) intel_uncore(E) 
> crc16(E) wmi_bmof(E) rfkill(E) mei_me(E) iTCO_vendor_support(E) 
> ipmi_si(E) snd(E) watchdog(E) mei(E) video(E) soundcore(E) 
> ipmi_devintf(E) ipmi_msghandler(E) joydev(E) evdev(E) sg(E) msr(E) 
> parport_pc(E) ppdev(E) nfsd(E) lp(E) parport(E) auth_rpcgss(E) 
> nfs_acl(E) lockd(E) grace(E) loop(E) efi_pstore(E) configfs(E) 
> sunrpc(E) ip_tables(E) x_tables(E) autofs4(E)
> btrfs(E) blake2b_generic(E) zstd_compress(E) efivarfs(E) raid10(E) 
> sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_plantronics(E) 
> hid_logitech_dj(E) hid_generic(E) uas(E) usbhid(E) hid(E) 
> usb_storage(E) raid456(E) async_raid6_recov(E) async_memcpy(E) 
> async_pq(E) async_xor(E) async_tx(E) xor(E) raid1(E) raid0(E) 
> raid6_pq(E) dm_mod(E) crc32c_intel(E) md_mod(E) sd_mod(E) ast(E) 
> drm_vram_helper(E) drm_ttm_helper(E) ghash_clmulni_intel(E) ttm(E) 
> sha512_ssse3(E) sha256_ssse3(E) drm_kms_helper(E) sha1_ssse3(E) ahci(E) 
> libahci(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) 
> aesni_intel(E) nvme(E) mxm_wmi(E) igb(E) libata(E) crypto_simd(E) 
> i2c_i801(E) cryptd(E) drm(E) dca(E) i2c_smbus(E) lpc_ich(E) usbcore(E) 
> scsi_mod(E) i2c_algo_bit(E) nvme_core(E) t10_pi(E) usb_common(E) 
> scsi_common(E) i40e(E) wmi(E) button(E)
> CPU: 10 PID: 6240 Comm: Xorg Tainted: P           OE 6.1.128-amd64 #0
> Hardware name: ASUS All Series/X99-WS/IPMI, BIOS 4001 05/28/2019
> RIP: 0010:drm_copy_field+0xa2/0xb0 [drm]
> Code: 00 00 74 13 49 c7 45 00 00 00 00 00 eb e0 0f 0b b8 f2 ff ff ff eb 
> d9 48 c7 c7 70 cb 17 c1 c6 05 43 17 07 00 01 e8 2e 09 57 dd <0f> 0b eb 
> d6 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 0f 1f 44 00
> RSP: 0018:ffffbd9941b0fba8 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: ffffbd9941b0fc60 RCX: 0000000000000027
> RDX: ffff9ec3bf6a13a8 RSI: 0000000000000001 RDI: ffff9ec3bf6a13a0
> RBP: ffff9e8487476800 R08: 0000000000000000 R09: ffffbd9941b0fa20
> R10: 0000000000000003 R11: ffff9ec3bff15ee8 R12: ffffffffc1132570
> R13: ffffbd9941b0fc80 R14: ffff9e85881d7200 R15: 0000000000000040
> FS:  00007f59dd209ac0(0000) GS:ffff9ec3bf680000(0000) 
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000056272a2123d0 CR3: 000000010c396005 CR4: 00000000003706e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> ? __warn+0x81/0xd0
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? report_bug+0xe6/0x150
> ? handle_bug+0x41/0x70
> ? exc_invalid_op+0x17/0x70
> ? asm_exc_invalid_op+0x1a/0x20
> ? drm_ioctl_flags+0x50/0x50 [drm]
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? drm_copy_field+0xa2/0xb0 [drm]
> ? drm_ioctl_flags+0x50/0x50 [drm]
> drm_version+0x73/0xa0 [drm]
> drm_ioctl_kernel+0xcd/0x170 [drm]
> drm_ioctl+0x233/0x410 [drm]
> ? drm_ioctl_flags+0x50/0x50 [drm]
> __x64_sys_ioctl+0x94/0xd0
> do_syscall_64+0x59/0xb0
> ? vfs_write+0x2b1/0x3f0
> ? vfs_write+0x2b1/0x3f0
> ? ksys_write+0x6f/0xf0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? __x64_sys_fcntl+0x94/0xc0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? syscall_exit_to_user_mode+0x22/0x40
> ? do_syscall_64+0x65/0xb0
> ? exit_to_user_mode_prepare+0x40/0x1e0
> entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> RIP: 0033:0x7f59dd31ccdb
> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 
> 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 
> 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> RSP: 002b:00007fff22f5d440 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 000056272a211f10 RCX: 00007f59dd31ccdb
> RDX: 000056272a211f10 RSI: 00000000c0406400 RDI: 000000000000000e
> RBP: 000056272a211f10 R08: 00007f59dd3f1cc0 R09: 0000000000000070
> R10: 00007f59dd236378 R11: 0000000000000246 R12: 00000000c0406400
> R13: 000000000000000e R14: 000000000000000e R15: 000056272a211510
> </TASK>
> ---[ end trace 0000000000000000 ]---
> 
> Maybe my Xorg is too recent (but I hope not) as I don't want to 
> downgrade Xorg (nor reinstall an older debian version) so I will try 
> another kernel version...
> 6.1.128 was build by me and maybe the 'make olddefconfig' from mainline 
> to 6.1.128 lost too many options (for ex 
> device-drivers/graphic-support>drm does not exist in menuconfig and I 
> found AST module directly in device-drivers/graphic-support ...)
> 6.1.124 exist prepackaged by Debian so it .config should be more 
> generic so I will test it
> 
> Thanks again for help,
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-14 16:01, Nicolas Baranger a écrit :
> 
> Hi Thomas
> 
> Thanks again for help
> 
> 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.
> Ok, I will try to find a working kernel and to git bisect to find the 
> commit which introduce the problem.
> I will start with longterm 6.1.128
> 
> Kind regards
> Nicolas
> 
> Le 2025-02-14 13:36, Thomas Zimmermann a écrit :
> 
> 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,

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

[Jani Nikula]

On Thu, 13 Feb 2025, Nicolas Baranger <nicolas.baranger@3xo.fr> wrote:
> Yes, due to .date total removal in linux 6.14 
> (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/

I'm not sure what you're trying to say here. The driver date was removed
because it was virtually never updated for any driver. It provided no
useful information.

BR,
Jani.


-- 
Jani Nikula, Intel

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

[Nicolas Baranger]

Hi Jani

> I'm not sure what you're trying to say here. The driver date was 
> removed
> because it was virtually never updated for any driver. It provided no
> useful information.

Sure your right, when I removed it from NVIDIA driver (to be able to 
build nvidia driver with DKMS on mainline), the .date value was still 
set to 20160202 !
See the PR here 
https://github.com/NVIDIA/open-gpu-kernel-modules/pull/783

I did just say that to be able to build and use the ast_new on mainline 
(6.14-rcX) I had to update the source which were working on linux-stable 
and to remove .date from drm structure.
That's why on the online directory there are 2 versions of the driver, 
one for linux-stable (up to 6.13.2) and one for mainline (from 
6.14.0-rc1).

Kind regards
Nicolas Baranger



Le 2025-02-24 09:53, Jani Nikula a écrit :

> On Thu, 13 Feb 2025, Nicolas Baranger <nicolas.baranger@3xo.fr> wrote:
> 
>> Yes, due to .date total removal in linux 6.14
>> (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/
> 
> I'm not sure what you're trying to say here. The driver date was 
> removed
> because it was virtually never updated for any driver. It provided no
> useful information.
> 
> BR,
> Jani.

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

[Thomas Zimmermann]

Hi

Am 11.02.25 um 19:15 schrieb Nicolas Baranger:
> Dear maintener
>
> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
> driver on mainline kernel (6.13.0 + 6.13.1).
>
> ASPEED video driver is availiable here:
> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>
> But it only work for LTS kernel
> So I modify the DKMS package and I build a new Debian DKMS package 
> with the adapted  source.
> My patch can be find here :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
> See the README:
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>
> Using this new 'ast 1.15.1' driver, performance are amazing compared 
> to the 'ast' driver include in kernel tree, specially when using a 
> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
> as the main video card and as the main and only video output (the 
> discrete GPU is used only for offloading 3D or for cuda/opencl)

You are using NVidia's proprietary driver, right? Did you reach out to 
them wrt this problem? Or searched their support forums, online help, 
etc? If so, what are the results?

Best regards
Thomas

>
>
> So to make things easier, I include the new 'ast 1.15.1' driver in 
> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
> It's working fine as you can see on this video :
> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
>
>
> I upload all the work I've done here :
> https://xba.soartist.net/ast-drm_nba_20250211/
>
> See the global README :
> https://xba.soartist.net/ast-drm_nba_20250211/README
>
> and the README in nba-kernel sub-directory :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>
> I'm not a developer so please let me know if I made the things the 
> right way and if this new 'ast 1.15.1' driver can be ported to 
> linux-next or linux-? ?
> If you need more explanations, do not hesitate to contact me, I would 
> be happy to help
>
> Kind regards
> Nicolas Baranger

-- 
--
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)

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

[Nicolas Baranger]

Dear Thomas

> You are using NVidia's proprietary driver, right? Did you reach out to 
> them wrt this problem? Or searched their support forums, online help, 
> etc? If so, what are the results?

Yes I'm using NVidia propriétary driver.
Maybe I'm wrong but I did not ask their support directly because first, 
for me it seems that there is no issue with the NVidia driver and 
unfortunately NVidia is not as opensource mind as Linux kernel community 
(as an example you can have a look on my last PR here 
https://github.com/NVIDIA/open-gpu-kernel-modules/pull/783 which had not 
been reviewed since 3+ weeks... and without this PR, it's impossible to 
build open or closed source NVidia drivers on mainline)

Second, I thought I already report it here but on my system using a 
recent kernel and embeded ast 0.1.0 driver has a very poor rendering and 
graphic is very slow, twinkle is high, had poor colors and it's 
happenning even if the NVidia driver is unloaded
The screen flickering is high too and it's like if I was using an old 
cathode ray tube monitor (I'm using an LCD monitor which display a nice 
and eyes confortable picture when using ast 1.15.1 driver or when 
displaying directly the video output of the Nvidia GPU(using HDMI 
output)).
Third, approximately from Linux 6.10+ using the embeded ast driver I 
have some lag when sliding a window on Gnome desktop (Xorg not Wayland) 
and CPU is highly used (some coreS at 100%), but I do not have those lag 
with ast 1.15.1 and CPU is less used (1 core at less than 80% max)
For the moment, I think Linux 6.12.9 is the worst I constat

Last, I found that Linux 6.1.128 is working perfectly out of the box 
with embeded ast 0.1.0 driver and there is a manifest lost of 
performances with Vulkan and Nvidia prime render offload when upgrading 
to Linux 6.2 (using same NVidia driver version, I did test those 3 
versions  535.216.01, 550.142, and 550.144.03 with similar results).
But in Linux 6.2, except the lost of performances, I did not constat the 
poor rendering and twinkle on the screen nor lag when sliding a window 
on the desktop or too high CPU usage.

So I suspect there is something else introduced between Linux 6.2 and 
mainline which cause this behavior.

I'm continuing bissection and I'm sorry, it's not as fast as I would as 
each tests tooks some times and I must never tell something wrong to git 
if I don't want to restart all the work...

Thanks again for answer and help

Kind regards
Nicolas Baranger


Le 2025-02-28 11:06, Thomas Zimmermann a écrit :

> Hi
> 
> Am 11.02.25 um 19:15 schrieb Nicolas Baranger:
> 
>> Dear maintener
>> 
>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>> driver on mainline kernel (6.13.0 + 6.13.1).
>> 
>> ASPEED video driver is availiable here:
>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>> 
>> But it only work for LTS kernel
>> So I modify the DKMS package and I build a new Debian DKMS package 
>> with the adapted  source.
>> My patch can be find here :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
>> See the README:
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>> 
>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>> to the 'ast' driver include in kernel tree, specially when using a 
>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>> as the main video card and as the main and only video output (the 
>> discrete GPU is used only for offloading 3D or for cuda/opencl)
> 
> You are using NVidia's proprietary driver, right? Did you reach out to 
> them wrt this problem? Or searched their support forums, online help, 
> etc? If so, what are the results?
> 
> Best regards
> Thomas
> 
>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>> It's working fine as you can see on this video :
>> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
>> I upload all the work I've done here :
>> https://xba.soartist.net/ast-drm_nba_20250211/
>> 
>> See the global README :
>> https://xba.soartist.net/ast-drm_nba_20250211/README
>> 
>> and the README in nba-kernel sub-directory :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>> 
>> I'm not a developer so please let me know if I made the things the 
>> right way and if this new 'ast 1.15.1' driver can be ported to 
>> linux-next or linux-? ?
>> If you need more explanations, do not hesitate to contact me, I would 
>> be happy to help
>> 
>> Kind regards
>> Nicolas Baranger

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

[Thomas Zimmermann]

Hi

Am 03.03.25 um 09:07 schrieb Nicolas Baranger:
> Dear Thomas
>
>> You are using NVidia's proprietary driver, right? Did you reach out 
>> to them wrt this problem? Or searched their support forums, online 
>> help, etc? If so, what are the results?
>
> Yes I'm using NVidia propriétary driver.
> Maybe I'm wrong but I did not ask their support directly because 
> first, for me it seems that there is no issue with the NVidia driver 
> and unfortunately NVidia is not as opensource mind as Linux kernel 
> community (as an example you can have a look on my last PR here 
> https://github.com/NVIDIA/open-gpu-kernel-modules/pull/783 which had 
> not been reviewed since 3+ weeks... and without this PR, it's 
> impossible to build open or closed source NVidia drivers on mainline)

I see.

I do have an idea what might be happening here. You are using 6.13.1, 
right?  If I give you a patch file for this kernel, are you able to 
apply it (with 'git am') for testing and report the kernel's logging output?

Best regards
Thomas

>
> Second, I thought I already report it here but on my system using a 
> recent kernel and embeded ast 0.1.0 driver has a very poor rendering 
> and graphic is very slow, twinkle is high, had poor colors and it's 
> happenning even if the NVidia driver is unloaded
> The screen flickering is high too and it's like if I was using an old 
> cathode ray tube monitor (I'm using an LCD monitor which display a 
> nice and eyes confortable picture when using ast 1.15.1 driver or when 
> displaying directly the video output of the Nvidia GPU(using HDMI 
> output)).
> Third, approximately from Linux 6.10+ using the embeded ast driver I 
> have some lag when sliding a window on Gnome desktop (Xorg not 
> Wayland) and CPU is highly used (some coreS at 100%), but I do not 
> have those lag with ast 1.15.1 and CPU is less used (1 core at less 
> than 80% max)
> For the moment, I think Linux 6.12.9 is the worst I constat
>
> Last, I found that Linux 6.1.128 is working perfectly out of the box 
> with embeded ast 0.1.0 driver and there is a manifest lost of 
> performances with Vulkan and Nvidia prime render offload when 
> upgrading to Linux 6.2 (using same NVidia driver version, I did test 
> those 3 versions  535.216.01, 550.142, and 550.144.03 with similar 
> results).
> But in Linux 6.2, except the lost of performances, I did not constat 
> the poor rendering and twinkle on the screen nor lag when sliding a 
> window on the desktop or too high CPU usage.
>
> So I suspect there is something else introduced between Linux 6.2 and 
> mainline which cause this behavior.
>
> I'm continuing bissection and I'm sorry, it's not as fast as I would 
> as each tests tooks some times and I must never tell something wrong 
> to git if I don't want to restart all the work...
>
> Thanks again for answer and help
>
> Kind regards
> Nicolas Baranger
>
>
> Le 2025-02-28 11:06, Thomas Zimmermann a écrit :
>
>> Hi
>>
>> Am 11.02.25 um 19:15 schrieb Nicolas Baranger:
>>
>>> Dear maintener
>>>
>>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>>> driver on mainline kernel (6.13.0 + 6.13.1).
>>>
>>> ASPEED video driver is availiable here:
>>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>>>
>>> But it only work for LTS kernel
>>> So I modify the DKMS package and I build a new Debian DKMS package 
>>> with the adapted  source.
>>> My patch can be find here :
>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
>>> See the README:
>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>>>
>>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>>> to the 'ast' driver include in kernel tree, specially when using a 
>>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>>> as the main video card and as the main and only video output (the 
>>> discrete GPU is used only for offloading 3D or for cuda/opencl)
>>
>> You are using NVidia's proprietary driver, right? Did you reach out 
>> to them wrt this problem? Or searched their support forums, online 
>> help, etc? If so, what are the results?
>>
>> Best regards
>> Thomas
>>
>>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>>> It's working fine as you can see on this video :
>>> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
>>> I upload all the work I've done here :
>>> https://xba.soartist.net/ast-drm_nba_20250211/
>>>
>>> See the global README :
>>> https://xba.soartist.net/ast-drm_nba_20250211/README
>>>
>>> and the README in nba-kernel sub-directory :
>>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>>>
>>> I'm not a developer so please let me know if I made the things the 
>>> right way and if this new 'ast 1.15.1' driver can be ported to 
>>> linux-next or linux-? ?
>>> If you need more explanations, do not hesitate to contact me, I 
>>> would be happy to help
>>>
>>> Kind regards
>>> Nicolas Baranger

-- 
--
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)

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

[Nicolas Baranger]

Hi Thomas

> I do have an idea what might be happening here. You are using 6.13.1, 
> right?  If I give you a patch file for this kernel, are you able to 
> apply it (with 'git am') for testing and report the kernel's logging 
> output?

Yes I'm using Linux 6.13.1 but I can also test with the latest 
linux-stable 6.13.5 or on mainline, whatever help you the best.
The only thing is I cannot go before Linux 6.13+ because it it fix DIO 
write on netfs (regression introduced in 6.10) and I'm using this 
feature for backups.

I think I should be able to patch and use 'git am' (In the worst there's 
always https://git-scm.com/docs/git-am), and I would be happy to report 
the kernel logging output

Thanks again for help

Kind regards
Nicolas Baranger

Le 2025-03-03 09:19, Thomas Zimmermann a écrit :

> Hi
> 
> Am 03.03.25 um 09:07 schrieb Nicolas Baranger: Dear Thomas
> 
> You are using NVidia's proprietary driver, right? Did you reach out to 
> them wrt this problem? Or searched their support forums, online help, 
> etc? If so, what are the results?
> Yes I'm using NVidia propriétary driver.
> Maybe I'm wrong but I did not ask their support directly because first, 
> for me it seems that there is no issue with the NVidia driver and 
> unfortunately NVidia is not as opensource mind as Linux kernel 
> community (as an example you can have a look on my last PR here 
> https://github.com/NVIDIA/open-gpu-kernel-modules/pull/783 which had 
> not been reviewed since 3+ weeks... and without this PR, it's 
> impossible to build open or closed source NVidia drivers on mainline)

I see.

I do have an idea what might be happening here. You are using 6.13.1, 
right?  If I give you a patch file for this kernel, are you able to 
apply it (with 'git am') for testing and report the kernel's logging 
output?

Best regards
Thomas

> Second, I thought I already report it here but on my system using a 
> recent kernel and embeded ast 0.1.0 driver has a very poor rendering 
> and graphic is very slow, twinkle is high, had poor colors and it's 
> happenning even if the NVidia driver is unloaded
> The screen flickering is high too and it's like if I was using an old 
> cathode ray tube monitor (I'm using an LCD monitor which display a nice 
> and eyes confortable picture when using ast 1.15.1 driver or when 
> displaying directly the video output of the Nvidia GPU(using HDMI 
> output)).
> Third, approximately from Linux 6.10+ using the embeded ast driver I 
> have some lag when sliding a window on Gnome desktop (Xorg not Wayland) 
> and CPU is highly used (some coreS at 100%), but I do not have those 
> lag with ast 1.15.1 and CPU is less used (1 core at less than 80% max)
> For the moment, I think Linux 6.12.9 is the worst I constat
> 
> Last, I found that Linux 6.1.128 is working perfectly out of the box 
> with embeded ast 0.1.0 driver and there is a manifest lost of 
> performances with Vulkan and Nvidia prime render offload when upgrading 
> to Linux 6.2 (using same NVidia driver version, I did test those 3 
> versions  535.216.01, 550.142, and 550.144.03 with similar results).
> But in Linux 6.2, except the lost of performances, I did not constat 
> the poor rendering and twinkle on the screen nor lag when sliding a 
> window on the desktop or too high CPU usage.
> 
> So I suspect there is something else introduced between Linux 6.2 and 
> mainline which cause this behavior.
> 
> I'm continuing bissection and I'm sorry, it's not as fast as I would as 
> each tests tooks some times and I must never tell something wrong to 
> git if I don't want to restart all the work...
> 
> Thanks again for answer and help
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-02-28 11:06, Thomas Zimmermann a écrit :
> 
> Hi
> 
> Am 11.02.25 um 19:15 schrieb Nicolas Baranger:
> 
> Dear maintener
> 
> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
> driver on mainline kernel (6.13.0 + 6.13.1).
> 
> ASPEED video driver is availiable here:
> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
> 
> But it only work for LTS kernel
> So I modify the DKMS package and I build a new Debian DKMS package with 
> the adapted  source.
> My patch can be find here :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
> See the README:
> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
> 
> Using this new 'ast 1.15.1' driver, performance are amazing compared to 
> the 'ast' driver include in kernel tree, specially when using a 
> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card as 
> the main video card and as the main and only video output (the discrete 
> GPU is used only for offloading 3D or for cuda/opencl)
> You are using NVidia's proprietary driver, right? Did you reach out to 
> them wrt this problem? Or searched their support forums, online help, 
> etc? If so, what are the results?
> 
> Best regards
> Thomas
> 
> So to make things easier, I include the new 'ast 1.15.1' driver in 
> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
> It's working fine as you can see on this video :
> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
> I upload all the work I've done here :
> https://xba.soartist.net/ast-drm_nba_20250211/
> 
> See the global README :
> https://xba.soartist.net/ast-drm_nba_20250211/README
> 
> and the README in nba-kernel sub-directory :
> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
> 
> I'm not a developer so please let me know if I made the things the 
> right way and if this new 'ast 1.15.1' driver can be ported to 
> linux-next or linux-? ?
> If you need more explanations, do not hesitate to contact me, I would 
> be happy to help
> 
> Kind regards
> Nicolas Baranger

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

[Thomas Zimmermann]

[-- Attachment #1: Type: text/plain, Size: 6553 bytes --]

(cc'ing Jocelyn)

Am 03.03.25 um 09:44 schrieb Nicolas Baranger:
> Hi Thomas
>
>> I do have an idea what might be happening here. You are using 6.13.1, 
>> right?  If I give you a patch file for this kernel, are you able to 
>> apply it (with 'git am') for testing and report the kernel's logging 
>> output?
>
> Yes I'm using Linux 6.13.1 but I can also test with the latest 
> linux-stable 6.13.5 or on mainline, whatever help you the best.
> The only thing is I cannot go before Linux 6.13+ because it it fix DIO 
> write on netfs (regression introduced in 6.10) and I'm using this 
> feature for backups.
>
> I think I should be able to patch and use 'git am' (In the worst 
> there's always https://git-scm.com/docs/git-am), and I would be happy 
> to report the kernel logging output

Great. You'll find a patch attached against the 6.13 kernel. Let me know 
if it doesn't apply.

If it applies, please run your performance test and look at the dmesg 
output. It should contain warnings about shared GEM objects. Can you 
please report some of this output?

Best regards
Thomas

>
> Thanks again for help
>
> Kind regards
> Nicolas Baranger
>
> Le 2025-03-03 09:19, Thomas Zimmermann a écrit :
>
>> Hi
>>
>> Am 03.03.25 um 09:07 schrieb Nicolas Baranger: Dear Thomas
>>
>> You are using NVidia's proprietary driver, right? Did you reach out 
>> to them wrt this problem? Or searched their support forums, online 
>> help, etc? If so, what are the results?
>> Yes I'm using NVidia propriétary driver.
>> Maybe I'm wrong but I did not ask their support directly because 
>> first, for me it seems that there is no issue with the NVidia driver 
>> and unfortunately NVidia is not as opensource mind as Linux kernel 
>> community (as an example you can have a look on my last PR here 
>> https://github.com/NVIDIA/open-gpu-kernel-modules/pull/783 which had 
>> not been reviewed since 3+ weeks... and without this PR, it's 
>> impossible to build open or closed source NVidia drivers on mainline)
>
> I see.
>
> I do have an idea what might be happening here. You are using 6.13.1, 
> right?  If I give you a patch file for this kernel, are you able to 
> apply it (with 'git am') for testing and report the kernel's logging 
> output?
>
> Best regards
> Thomas
>
>> Second, I thought I already report it here but on my system using a 
>> recent kernel and embeded ast 0.1.0 driver has a very poor rendering 
>> and graphic is very slow, twinkle is high, had poor colors and it's 
>> happenning even if the NVidia driver is unloaded
>> The screen flickering is high too and it's like if I was using an old 
>> cathode ray tube monitor (I'm using an LCD monitor which display a 
>> nice and eyes confortable picture when using ast 1.15.1 driver or 
>> when displaying directly the video output of the Nvidia GPU(using 
>> HDMI output)).
>> Third, approximately from Linux 6.10+ using the embeded ast driver I 
>> have some lag when sliding a window on Gnome desktop (Xorg not 
>> Wayland) and CPU is highly used (some coreS at 100%), but I do not 
>> have those lag with ast 1.15.1 and CPU is less used (1 core at less 
>> than 80% max)
>> For the moment, I think Linux 6.12.9 is the worst I constat
>>
>> Last, I found that Linux 6.1.128 is working perfectly out of the box 
>> with embeded ast 0.1.0 driver and there is a manifest lost of 
>> performances with Vulkan and Nvidia prime render offload when 
>> upgrading to Linux 6.2 (using same NVidia driver version, I did test 
>> those 3 versions  535.216.01, 550.142, and 550.144.03 with similar 
>> results).
>> But in Linux 6.2, except the lost of performances, I did not constat 
>> the poor rendering and twinkle on the screen nor lag when sliding a 
>> window on the desktop or too high CPU usage.
>>
>> So I suspect there is something else introduced between Linux 6.2 and 
>> mainline which cause this behavior.
>>
>> I'm continuing bissection and I'm sorry, it's not as fast as I would 
>> as each tests tooks some times and I must never tell something wrong 
>> to git if I don't want to restart all the work...
>>
>> Thanks again for answer and help
>>
>> Kind regards
>> Nicolas Baranger
>>
>> Le 2025-02-28 11:06, Thomas Zimmermann a écrit :
>>
>> Hi
>>
>> Am 11.02.25 um 19:15 schrieb Nicolas Baranger:
>>
>> Dear maintener
>>
>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>> driver on mainline kernel (6.13.0 + 6.13.1).
>>
>> ASPEED video driver is availiable here:
>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>>
>> But it only work for LTS kernel
>> So I modify the DKMS package and I build a new Debian DKMS package 
>> with the adapted  source.
>> My patch can be find here :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
>> See the README:
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>>
>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>> to the 'ast' driver include in kernel tree, specially when using a 
>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>> as the main video card and as the main and only video output (the 
>> discrete GPU is used only for offloading 3D or for cuda/opencl)
>> You are using NVidia's proprietary driver, right? Did you reach out 
>> to them wrt this problem? Or searched their support forums, online 
>> help, etc? If so, what are the results?
>>
>> Best regards
>> Thomas
>>
>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>> It's working fine as you can see on this video :
>> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
>> I upload all the work I've done here :
>> https://xba.soartist.net/ast-drm_nba_20250211/
>>
>> See the global README :
>> https://xba.soartist.net/ast-drm_nba_20250211/README
>>
>> and the README in nba-kernel sub-directory :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>>
>> I'm not a developer so please let me know if I made the things the 
>> right way and if this new 'ast 1.15.1' driver can be ported to 
>> linux-next or linux-? ?
>> If you need more explanations, do not hesitate to contact me, I would 
>> be happy to help
>>
>> Kind regards
>> Nicolas Baranger

-- 
--
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)

[-- Attachment #2: 0001-warn-if-shared-buffers-are-in-I-O-memory.patch --]
[-- Type: text/x-patch, Size: 998 bytes --]

From c86d874350ba6dd67cc79fa3f763c126bc9dc987 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 3 Mar 2025 11:12:10 +0100
Subject: [PATCH] warn if shared buffers are in I/O memory

---
 drivers/gpu/drm/ast/ast_mode.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c3b950675485..44781f7b7339 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -505,6 +505,15 @@ static void ast_handle_damage(struct ast_plane *ast_plane, struct iosys_map *src
 {
 	struct iosys_map dst = IOSYS_MAP_INIT_VADDR_IOMEM(ast_plane->vaddr);
 
+	{
+		struct drm_gem_object *gem = fb->obj[0];
+
+		if (gem && gem->dma_buf) {
+			drm_warn(fb->dev, "GEM object is shared, located in I/O memory: %d\n",
+				 src->is_iomem);
+		}
+	}
+
 	iosys_map_incr(&dst, drm_fb_clip_offset(fb->pitches[0], fb->format, clip));
 	drm_fb_memcpy(&dst, fb->pitches, src, fb, clip);
 }
-- 
2.48.1

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

[Nicolas Baranger]

Hi Thomas

> Great. You'll find a patch attached against the 6.13 kernel. Let me 
> know if it doesn't apply.

> If it applies, please run your performance test and look at the dmesg 
> output. It should contain warnings about shared GEM objects. Can you 
> please report some of this output?

Thanks a lot, I'm comming back here after testing

King regards
Nicolas Baranger


Le 2025-03-03 11:16, Thomas Zimmermann a écrit :

> (cc'ing Jocelyn)
> 
> Am 03.03.25 um 09:44 schrieb Nicolas Baranger: Hi Thomas
> 
> I do have an idea what might be happening here. You are using 6.13.1, 
> right?  If I give you a patch file for this kernel, are you able to 
> apply it (with 'git am') for testing and report the kernel's logging 
> output?
> Yes I'm using Linux 6.13.1 but I can also test with the latest 
> linux-stable 6.13.5 or on mainline, whatever help you the best.
> The only thing is I cannot go before Linux 6.13+ because it it fix DIO 
> write on netfs (regression introduced in 6.10) and I'm using this 
> feature for backups.
> 
> I think I should be able to patch and use 'git am' (In the worst 
> there's always https://git-scm.com/docs/git-am), and I would be happy 
> to report the kernel logging output

Great. You'll find a patch attached against the 6.13 kernel. Let me know 
if it doesn't apply.

If it applies, please run your performance test and look at the dmesg 
output. It should contain warnings about shared GEM objects. Can you 
please report some of this output?

Best regards
Thomas

> Thanks again for help
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-03-03 09:19, Thomas Zimmermann a écrit :
> 
>> Hi
>> 
>> Am 03.03.25 um 09:07 schrieb Nicolas Baranger: Dear Thomas
>> 
>> You are using NVidia's proprietary driver, right? Did you reach out to 
>> them wrt this problem? Or searched their support forums, online help, 
>> etc? If so, what are the results?
>> Yes I'm using NVidia propriétary driver.
>> Maybe I'm wrong but I did not ask their support directly because 
>> first, for me it seems that there is no issue with the NVidia driver 
>> and unfortunately NVidia is not as opensource mind as Linux kernel 
>> community (as an example you can have a look on my last PR here 
>> https://github.com/NVIDIA/open-gpu-kernel-modules/pull/783 which had 
>> not been reviewed since 3+ weeks... and without this PR, it's 
>> impossible to build open or closed source NVidia drivers on mainline)
> 
> I see.
> 
> I do have an idea what might be happening here. You are using 6.13.1, 
> right?  If I give you a patch file for this kernel, are you able to 
> apply it (with 'git am') for testing and report the kernel's logging 
> output?
> 
> Best regards
> Thomas
> 
>> Second, I thought I already report it here but on my system using a 
>> recent kernel and embeded ast 0.1.0 driver has a very poor rendering 
>> and graphic is very slow, twinkle is high, had poor colors and it's 
>> happenning even if the NVidia driver is unloaded
>> The screen flickering is high too and it's like if I was using an old 
>> cathode ray tube monitor (I'm using an LCD monitor which display a 
>> nice and eyes confortable picture when using ast 1.15.1 driver or when 
>> displaying directly the video output of the Nvidia GPU(using HDMI 
>> output)).
>> Third, approximately from Linux 6.10+ using the embeded ast driver I 
>> have some lag when sliding a window on Gnome desktop (Xorg not 
>> Wayland) and CPU is highly used (some coreS at 100%), but I do not 
>> have those lag with ast 1.15.1 and CPU is less used (1 core at less 
>> than 80% max)
>> For the moment, I think Linux 6.12.9 is the worst I constat
>> 
>> Last, I found that Linux 6.1.128 is working perfectly out of the box 
>> with embeded ast 0.1.0 driver and there is a manifest lost of 
>> performances with Vulkan and Nvidia prime render offload when 
>> upgrading to Linux 6.2 (using same NVidia driver version, I did test 
>> those 3 versions  535.216.01, 550.142, and 550.144.03 with similar 
>> results).
>> But in Linux 6.2, except the lost of performances, I did not constat 
>> the poor rendering and twinkle on the screen nor lag when sliding a 
>> window on the desktop or too high CPU usage.
>> 
>> So I suspect there is something else introduced between Linux 6.2 and 
>> mainline which cause this behavior.
>> 
>> I'm continuing bissection and I'm sorry, it's not as fast as I would 
>> as each tests tooks some times and I must never tell something wrong 
>> to git if I don't want to restart all the work...
>> 
>> Thanks again for answer and help
>> 
>> Kind regards
>> Nicolas Baranger
>> 
>> Le 2025-02-28 11:06, Thomas Zimmermann a écrit :
>> 
>> Hi
>> 
>> Am 11.02.25 um 19:15 schrieb Nicolas Baranger:
>> 
>> Dear maintener
>> 
>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>> driver on mainline kernel (6.13.0 + 6.13.1).
>> 
>> ASPEED video driver is availiable here:
>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>> 
>> But it only work for LTS kernel
>> So I modify the DKMS package and I build a new Debian DKMS package 
>> with the adapted  source.
>> My patch can be find here :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
>> See the README:
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>> 
>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>> to the 'ast' driver include in kernel tree, specially when using a 
>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>> as the main video card and as the main and only video output (the 
>> discrete GPU is used only for offloading 3D or for cuda/opencl)
>> You are using NVidia's proprietary driver, right? Did you reach out to 
>> them wrt this problem? Or searched their support forums, online help, 
>> etc? If so, what are the results?
>> 
>> Best regards
>> Thomas
>> 
>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>> It's working fine as you can see on this video :
>> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
>> I upload all the work I've done here :
>> https://xba.soartist.net/ast-drm_nba_20250211/
>> 
>> See the global README :
>> https://xba.soartist.net/ast-drm_nba_20250211/README
>> 
>> and the README in nba-kernel sub-directory :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>> 
>> I'm not a developer so please let me know if I made the things the 
>> right way and if this new 'ast 1.15.1' driver can be ported to 
>> linux-next or linux-? ?
>> If you need more explanations, do not hesitate to contact me, I would 
>> be happy to help
>> 
>> Kind regards
>> Nicolas Baranger

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

[Nicolas Baranger]

Hi Thomas

I'm really sorry for the delay of 2 weeks (I lost a big raid array and 
it tooks days++ to recover, sorry)

As asked, I did patch linux-6.13.1 with the provided patch and I did use 
the original (but just patched) ast driver
Here you can find the video of the test:
https://xba.soartist.net/ast-drm_nba_20250211/vkcube_linux-6.13.1.2-ast-warn-nba0-1_20250315.webm

You will constat catastrophic performances, and CPU is doing all the job 
(from 4 to 10 core used for displaying Gnome Desktop)
Please note:
In the first minute of the video, I was sliding the 'file' window on the 
desktop (not too fast) from left to right and from up to down
It was lagging at a point that the sliding of the window does not 
appears on the video as if I was not sliding the window at all

In the second part (with vulkan cube) you can see that the cube round 
very very slowly and nvtop report 5% or 6% of usage of the discrete GPU 
(vs 25% to 50% with ast_new driver or linux 6.1.128 ast embeded driver).
It seems to be caused by ast very poor rendering (as if the driver was 
not doing its job)

Unfortunatly, no shared GEM objects were reported by dmesg or in regular 
syslog (I can email you privatly the whole dmesg output if needed)
dmesg -T  | grep -iE "obj|gem"
[sam. 15 mars 10:31:37 2025] SLUB: HWalign=64, Order=0-3, MinObjects=0, 
CPUs=40, Nodes=1

I was require to patch ast_mod.c at line 634 because in Linux 6.13.1 
static void ast_handle_damage start at line 629
Is there something I'm doing bad ?

Please note that linux-6.1.128 is the last version where the included 
ast driver as the same rendering and performance as ast_new I included 
in Linux 6.13+
Issues starting from Linux 6.2 and is more and more degraded until Linux 
6.13.1 which is currently the worst I constat (desktop becomes limit 
unusable without a big Xeon to do the video job and with that unsusable 
for doing something else than using a terminal).

Thanks again for help

Kind regards
Nicolas Baranger


Le 2025-03-03 11:16, Thomas Zimmermann a écrit :

> (cc'ing Jocelyn)
> 
> Am 03.03.25 um 09:44 schrieb Nicolas Baranger: Hi Thomas
> 
> I do have an idea what might be happening here. You are using 6.13.1, 
> right?  If I give you a patch file for this kernel, are you able to 
> apply it (with 'git am') for testing and report the kernel's logging 
> output?
> Yes I'm using Linux 6.13.1 but I can also test with the latest 
> linux-stable 6.13.5 or on mainline, whatever help you the best.
> The only thing is I cannot go before Linux 6.13+ because it it fix DIO 
> write on netfs (regression introduced in 6.10) and I'm using this 
> feature for backups.
> 
> I think I should be able to patch and use 'git am' (In the worst 
> there's always https://git-scm.com/docs/git-am), and I would be happy 
> to report the kernel logging output

Great. You'll find a patch attached against the 6.13 kernel. Let me know 
if it doesn't apply.

If it applies, please run your performance test and look at the dmesg 
output. It should contain warnings about shared GEM objects. Can you 
please report some of this output?

Best regards
Thomas

> Thanks again for help
> 
> Kind regards
> Nicolas Baranger
> 
> Le 2025-03-03 09:19, Thomas Zimmermann a écrit :
> 
>> Hi
>> 
>> Am 03.03.25 um 09:07 schrieb Nicolas Baranger: Dear Thomas
>> 
>> You are using NVidia's proprietary driver, right? Did you reach out to 
>> them wrt this problem? Or searched their support forums, online help, 
>> etc? If so, what are the results?
>> Yes I'm using NVidia propriétary driver.
>> Maybe I'm wrong but I did not ask their support directly because 
>> first, for me it seems that there is no issue with the NVidia driver 
>> and unfortunately NVidia is not as opensource mind as Linux kernel 
>> community (as an example you can have a look on my last PR here 
>> https://github.com/NVIDIA/open-gpu-kernel-modules/pull/783 which had 
>> not been reviewed since 3+ weeks... and without this PR, it's 
>> impossible to build open or closed source NVidia drivers on mainline)
> 
> I see.
> 
> I do have an idea what might be happening here. You are using 6.13.1, 
> right?  If I give you a patch file for this kernel, are you able to 
> apply it (with 'git am') for testing and report the kernel's logging 
> output?
> 
> Best regards
> Thomas
> 
>> Second, I thought I already report it here but on my system using a 
>> recent kernel and embeded ast 0.1.0 driver has a very poor rendering 
>> and graphic is very slow, twinkle is high, had poor colors and it's 
>> happenning even if the NVidia driver is unloaded
>> The screen flickering is high too and it's like if I was using an old 
>> cathode ray tube monitor (I'm using an LCD monitor which display a 
>> nice and eyes confortable picture when using ast 1.15.1 driver or when 
>> displaying directly the video output of the Nvidia GPU(using HDMI 
>> output)).
>> Third, approximately from Linux 6.10+ using the embeded ast driver I 
>> have some lag when sliding a window on Gnome desktop (Xorg not 
>> Wayland) and CPU is highly used (some coreS at 100%), but I do not 
>> have those lag with ast 1.15.1 and CPU is less used (1 core at less 
>> than 80% max)
>> For the moment, I think Linux 6.12.9 is the worst I constat
>> 
>> Last, I found that Linux 6.1.128 is working perfectly out of the box 
>> with embeded ast 0.1.0 driver and there is a manifest lost of 
>> performances with Vulkan and Nvidia prime render offload when 
>> upgrading to Linux 6.2 (using same NVidia driver version, I did test 
>> those 3 versions  535.216.01, 550.142, and 550.144.03 with similar 
>> results).
>> But in Linux 6.2, except the lost of performances, I did not constat 
>> the poor rendering and twinkle on the screen nor lag when sliding a 
>> window on the desktop or too high CPU usage.
>> 
>> So I suspect there is something else introduced between Linux 6.2 and 
>> mainline which cause this behavior.
>> 
>> I'm continuing bissection and I'm sorry, it's not as fast as I would 
>> as each tests tooks some times and I must never tell something wrong 
>> to git if I don't want to restart all the work...
>> 
>> Thanks again for answer and help
>> 
>> Kind regards
>> Nicolas Baranger
>> 
>> Le 2025-02-28 11:06, Thomas Zimmermann a écrit :
>> 
>> Hi
>> 
>> Am 11.02.25 um 19:15 schrieb Nicolas Baranger:
>> 
>> Dear maintener
>> 
>> For my own usage, I did make work the ASPEED ast-drm 1.15.1 video 
>> driver on mainline kernel (6.13.0 + 6.13.1).
>> 
>> ASPEED video driver is availiable here:
>> https://www.aspeedtech.com/file/support/Linux_DRM_1.15.1_4.tar.gz
>> 
>> But it only work for LTS kernel
>> So I modify the DKMS package and I build a new Debian DKMS package 
>> with the adapted  source.
>> My patch can be find here :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/astdiff.patch
>> See the README:
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-dkms/README
>> 
>> Using this new 'ast 1.15.1' driver, performance are amazing compared 
>> to the 'ast' driver include in kernel tree, specially when using a 
>> discrete GPU and offloading VULKAN / 3D on it but using AST VGA card 
>> as the main video card and as the main and only video output (the 
>> discrete GPU is used only for offloading 3D or for cuda/opencl)
>> You are using NVidia's proprietary driver, right? Did you reach out to 
>> them wrt this problem? Or searched their support forums, online help, 
>> etc? If so, what are the results?
>> 
>> Best regards
>> Thomas
>> 
>> So to make things easier, I include the new 'ast 1.15.1' driver in 
>> kernel tree as AST_NEW : linux-6.13.1-ast/drivers/gpu/drm/ast_new'
>> It's working fine as you can see on this video :
>> https://xba.soartist.net/ast-drm_nba_20250211/vulcan_nvidia_prime_render_offload_on_ast_vga_card.webm 
>> I upload all the work I've done here :
>> https://xba.soartist.net/ast-drm_nba_20250211/
>> 
>> See the global README :
>> https://xba.soartist.net/ast-drm_nba_20250211/README
>> 
>> and the README in nba-kernel sub-directory :
>> https://xba.soartist.net/ast-drm_nba_20250211/nba-kernel/README
>> 
>> I'm not a developer so please let me know if I made the things the 
>> right way and if this new 'ast 1.15.1' driver can be ported to 
>> linux-next or linux-? ?
>> If you need more explanations, do not hesitate to contact me, I would 
>> be happy to help
>> 
>> Kind regards
>> Nicolas Baranger