| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <7c378bfb-96e4-435d-8e6c-581d6851835f@suse.de> Date: Fri, 14 Feb 2025 13:36:46 +0100 From: Thomas Zimmermann <tzimmermann@...e.de> To: Jocelyn Falempe <jfalempe@...hat.com>, Nicolas Baranger <nicolas.baranger@....fr> Cc: dri-devel@...ts.freedesktop.org, airlied@...hat.com, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, linux-kernel@...r.kernel.org Subject: Re: Include ASPEED ast-drm 1.15.1 video driver in kernel tree 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@...it 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)
Powered by blists - more mailing lists