You are not logged in.
So the file chooser wasn't opening on zed so I installed xdg-desktop-portal-gtk but the applictions became really slow after that (Like obs), so I removed it. But now I feel like zed first time launch a bit slower that before (currently it takes 5 to 6 seconds). So xdg-desktop-portal-gtk do any changes that can persist after it has been removed ?
Compositor: hyprland
desktop portals installed: xdg-desktop-portal ; xdg-desktop-portal-hyprland
Last edited by mwooper (2024-06-27 15:24:56)
Offline
So xdg-desktop-portal-gtk do any changes that can persist after it has been removed ?
No. Also the xdg-portal stuff would typically case 25s delays for the dbus timeout.
Does zed also open slowly on manual invocation?
first time launch
https://archlinux.org/packages/extra/x86_64/zed/ is an electron client, they're notoriously bloated monstrosities - if only the first load (after a boot) is affected the bottleneck is likely disk IO
Offline
Okay
But zed isn't based on electron; (plus its written in rust)
and Micron's 2400 MTFDKBA1T0QFM is pretty fast (large Blender and Godot files open in like 0.5 to 2 seconds.)
Last edited by mwooper (2024-06-17 06:15:18)
Offline
Does zed also open slowly on manual invocation? … if only the first load (after a boot) is affected the bottleneck is likely disk IO
If you want to know what's stalling it, check iotop while starting it and in doubt strace the process.
But zed isn't based on electron
I might have gotten carried away by "creators of atom" but it's a 145MB binary what very much smells like electron "territory"…
(plus its written in rust)
Plus it could be written in assembler and that would not make a difference. If anything, rust will result in more bloat, not less.
Edit: on a cursory google it might be network - did youopt out of the telemtry stuff?
Edit #2: depending on what else you did, vulkan might be an issue - is it also slow to start while some other vulkan client (can be some simple demo) is running?
Last edited by seth (2024-06-17 06:33:13)
Offline
So these are the entries the get written in journalctl, as soon as I launch zed
Jun 20 17:21:43 mwoop kernel: [drm] PCIE GART of 512M enabled (table at 0x00000081FEB00000).
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: PSP is resuming...
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: reserve 0x1300000 from 0x81fc000000 for PSP TMR
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x00000035, smu fw if version = 0x00000040, smu fw>
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
Jun 20 17:21:43 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!
Jun 20 17:21:43 mwoop kernel: [drm] DMUB hardware initialized: version=0x07002A00
Jun 20 17:21:45 mwoop kernel: [drm] kiq ring mec 3 pipe 1 q 0
Jun 20 17:21:45 mwoop kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG decode initialized successfully.
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 1 on hub 8
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes
Jun 20 17:21:45 mwoop kernel: [drm] ring gfx_32787.1.1 was added
Jun 20 17:21:45 mwoop kernel: [drm] ring compute_32787.2.2 was added
Jun 20 17:21:45 mwoop kernel: [drm] ring sdma_32787.3.3 was added
Jun 20 17:21:45 mwoop kernel: [drm] ring gfx_32787.1.1 ib test pass
Jun 20 17:21:45 mwoop kernel: [drm] ring compute_32787.2.2 ib test pass
Jun 20 17:21:45 mwoop kernel: [drm] ring sdma_32787.3.3 ib test passLast edited by mwooper (2024-06-21 03:10:03)
Offline
Plus I have noticed when in same session is only quick start sometimes, but sometimes it takes same amount of time to launch and at that time in writes same entries to the journalctl.
and the same entries are written in journalctl when i run btop
Last edited by mwooper (2024-06-20 12:45:14)
Offline
Please use [code][/code] tags. Edit your post in this regard.
Jun 20 17:21:45 mwoop kernel: amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizesIs this a hybrid graphics system?
Does zed somehow end up using DRI_PRIME or the GPU by other means?
Offline
Yes its a hybrid system
inxi -G output:
Graphics:
Device-1: AMD Navi 33 [Radeon RX 7700S/7600/7600S/7600M XT/PRO W7600]
driver: amdgpu v: kernel
Device-2: AMD Phoenix1 driver: amdgpu v: kernel
Device-3: Sonix USB2.0 HD UVC WebCam driver: uvcvideo type: USB
Display: wayland server: X.Org v: 24.1 with: Xwayland v: 24.1.0
compositor: Hyprland v: 0.41.1-58-g7f09646a driver: X: loaded: modesetting
dri: radeonsi gpu: amdgpu resolution: 1280x800~165Hz
API: EGL v: 1.5 drivers: radeonsi,swrast
platforms: wayland,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.1.1-arch1.1
renderer: AMD Radeon 780M (radeonsi gfx1103_r1 LLVM 17.0.6 DRM 3.57
6.9.5-arch1-1)
API: Vulkan v: 1.3.279 drivers: amd surfaces: xcb,xlib,waylandDevice-1 is RX 7600S
Device-2 is integrated graphics of AMD Ryzen 9 7940HS
Does zed somehow end up using DRI_PRIME or the GPU by other means?
how do I figure which GPU its using?
Last edited by mwooper (2024-06-23 05:44:39)
Offline
Unless zed exposes that (like "about:gpu") you can't if it makes the selection internally (maybe w/ nvtop) but you could try to enforce the one it's supposed to use
https://wiki.archlinux.org/title/Vulkan … en_devices
Offline
So I installed vulkan-mesa-layers and then I ran
MESA_VK_DEVICE_SELECT=1002:15bf(Id for integrated graphics) but it still gives those same outputs and still takes same time to launch zed and btop.
Offline
It previosly certainly looked like zed is firing up the other GPU - is that still the case?
You could try the behavior in a single GPU context (remove one or disable it in the UEFI/BIOS) and file a bug at https://github.com/zed-industries/zed/issues on how to control the vulkan device
Offline
Try
MESA_VK_DEVICE_SELECT=1002:15bf!instead to enforce that only that GPU is visible to device queries. without the ! it will just shift the logical order but still present all avaialable devices to programs querying the vulkan devices.
Offline
Try
MESA_VK_DEVICE_SELECT=1002:15bf!instead to enforce that only that GPU is visible to device queries. without the ! it will just shift the logical order but still present all avaialable devices to programs querying the vulkan devices.
The result is still same
Offline
It previosly certainly looked like zed is firing up the other GPU - is that still the case?
You could try the behavior in a single GPU context (remove one or disable it in the UEFI/BIOS) and file a bug at https://github.com/zed-industries/zed/issues on how to control the vulkan device
When I run system with singleGPU config, the journalctl entries are not there but it still takes like 2.7 second (well better than 5 secs :-))
I will report the following to https://github.com/zed-industries/zed/issues
Last edited by mwooper (2024-06-27 15:46:13)
Offline