Forum Linux.général Vulkan, switch user et software vs hardware renderer

Posté par moi1392 le 24 novembre 2022 à 14:45. Licence CC By‑SA.

Étiquettes :

nov.

2022

Bonjour, j'ai un soucis avec vulkan quand j'essaye de lancer une appli avec un autre utilisateur que celui qui est logué dans la sessions graphique :

Voila mon workflow qui fonctionne très bien avec les applis OpenGL mais pas avec les applis Vulkan :

je me logue dans ma session graphique avec user1
j'ouvre un terminal, je coupe l'authentification à X : xhost +
je change d'utilisateur : su - user2 + MonSuperMotDePasseSecret (ne le retenez pas, il est secret…)
j'exporte le display : export DISPLAY=:0
je lance une appli OpenGL (glxgears ou glxinfo) => tout se passe bien
je lance une appli vulkan (vkgears ou vulkaninfo) => fail, ça passe en rendu software (llvmpipe)

info complémentaires :

distribution : debian sid
puce graphique : amd vega7 (integré à puce ryzen)
pilote libre à jour (version debian sid, mesa 22.2.4, vulkan 1.3.231)

avec user2, au début de vulkaninfo j'ai l'erreur suivante :
ERROR: [../src/amd/vulkan/radv_device.c:675] Code 0 : Could not open device /dev/dri/renderD128: Permission denied (VK_ERROR_INCOMPATIBLE_DRIVER)
Quand je regarde le fichier /dev/dri/renderD128 il est accessible par root et le groupe render (dans lequel aucun de mes user n'est)
bizarement, quand je fais un strace sur vulkaninfo avec l'user logué dans la sessions graphique, je vois passer l'open sur ce fichier qui réussi, et quand je le fait avec l'user qui n'est pas logué dans la session graphique, je vois bien l'open sur ce fichier qui échoue.
Je ne sais pas comment user1 est capable d'accéder à ce fichier, je n'ai pas plus creusé la question. Mais comment faire proprement pour que mon user2 puisse lancer une application vulkan ? Si c'est possible bien sur.

Bien sur, si j'inverse user1 et user2, j'ai exactement le même problème, il ne s'agit donc pas d'un problème lié à un user particulier de ma machine.

# vukan et X ou wayland ?

Posté par NeoX le 24 novembre 2022 à 16:30. Évalué à 3.

deja savoir si ton appli utilise enseuite X ou wayland

car la commande utilisée là :

j'ouvre un terminal, je coupe l'authentification à X : xhost +

ne fonctionne probablement que sous X ou pour les applis compatibles X11
- [^] # Re: vukan et X ou wayland ?
  
  Posté par moi1392 le 24 novembre 2022 à 23:28. Évalué à 2.
  
  tu peux faire le test toi même avec glxgears pur OpenGL et vkcube pour Vulkan.
  vkcube est compilé avec X sous debian.
# Groupe render

Posté par pepp le 25 novembre 2022 à 08:50. Évalué à 1.

Il faut que ton user2 soit dans le groupe render.

Je pense que OpenGL fonctionne parce qu'il obtient l'accès au GPU via X/GLX alors que Vulkan requiert l'accès direct.
- [^] # Re: Groupe render
  
  Posté par moi1392 le 25 novembre 2022 à 10:05. Évalué à 2.
  
  Je pense que OpenGL fonctionne parce qu'il obtient l'accès au GPU via X/GLX alors que Vulkan requiert l'accès direct.
  
  Je pense que c'est ça aussi.
  
  Il faut que ton user2 soit dans le groupe render.
  
  Tu as vu cette info quelque part ou tu réponds avec les infos de mon message ? Si tu as lu jusqu'au bout, ni user1, ni user2 sont dans le groupe render et je n'ai aucune idée de comment l'user logué dans la session graphique arrive à ouvrir ce fichier.
  Il faudrait en effet que je creuse de ce coté là mais j'espérais qu'il y aurait un moyen "officiel" (à la xhost par exemple) que quelqu'un connaitrait ici.
  - [^] # Re: Groupe render
    
    Posté par pepp le 25 novembre 2022 à 12:40. Évalué à 1.
    
    Je pense que user1 est dans le groupe video pour avoir le droit de lancer Xorg.
    
    Comme ce groupe gère /dev/dri/card0, je suppose qu'user1 hérite de la possibilité d'ouvrir /dev/dri/renderD128 (vu que c'est le même GPU, avec moins de droits).
    
    Cela étant dit, la bonne façon d'accèder au GPU pour GL/Vulkan c'est d'être dans le groupe render.
    xhost permet uniquement de communiquer avec X ; il se trouve que pour les applis GLX c'est également un moyen d'avoir accès au GPU.
    
    (et donc si user2 est ajouté à render, il faudra quand même utiliser xhost pour l'autoriser à discuter avec X pour créer sa fenêtre etc)
    - [^] # Re: Groupe render
      
      Posté par moi1392 le 29 novembre 2022 à 10:14. Évalué à 2.
      
      je me doutais bien que c'était la solution, mais je ne voulais pas le faire sans savoir pourquoi.
      En regardant de plus près, le fichier /dev/dri/renderD128 utilise des attributs de filesystem étendu et l'user logué est ajouté en rw sur ce fichier. Je n'ai pas creusé pour savoir qui fait ça, je suppose que c'est dans la stack Xorg/dri quelque part.
      
      De plus, la doc officielle debian indique bien que ce groupe sert à l'accès au périphérique de rendu.
      
      Donc voila, j'ai ajouté mes utilisateurs dans le groupe et le problème est réglé ;)
# ça ne résoudera pas ton problème

Posté par fearan le 28 novembre 2022 à 11:21. Évalué à 4.
mais xhost + est une très mauvaise idée
car ça donne de mauvais reflexes

a la rigueur
ssh -X user2@localhost

ou sans passer par ssh
faire
```
xauth list | grep "$DISPLAY "
```
copier la ligne (nomDeLaMachine…)

faire
```
su user2
xauth add la bonne ligne
```
sinon ya sux pour éviter de faire les commandes ;)

http://fgouget.free.fr/sux/sux-readme.shtml

Il ne faut pas décorner les boeufs avant d'avoir semé le vent
- [^] # Re: ça ne résoudera pas ton problème
  
  Posté par moi1392 le 29 novembre 2022 à 10:26. Évalué à 3. Dernière modification le 29 novembre 2022 à 10:26.
  
  mais xhost + est une très mauvaise idée
  
  Oui c'est vrai. Je ne sais pas pourquoi mais quand je tente un xhost +localhot ça ne marche pas comme je m'y attends.
  Dans le temps j'étais un peu plus bourrin et je copiais le cookie d'authentification (.Xauthority) depuis le home de l'user connecté vers l'autre. Je ne suis pas certain que ça soit une meilleur pratique et j'ai arreté.
  Je vais rententer ça en m'appliquant un peu plus.
  
  Sinon ssh -X te fait passer en indirect rendering pour OpenGL et tu te retrouves avec de l'OpenGL 1.1 (ça à peut-être changé depuis), en plus certaines applis alakon (firefox pour ne pas le nommer) trouv(ai)ent le moyen de foutre la merde et de se lancer localement avec l'utilisateur local, au final ça ne m'a jamais vraiment convenu sauf pour des trucs simples.
  
  PS: Pour firefox j'avais essayer un ssh -X à travers internet depuis un ami vers chez moi pour essayer de me connecter à un site avec mon ip de chez moi et pas celle de chez lui.
  Je hais les application qui essayent de faire des trucs "intelligent" en ne se comportant pas comme leur environement leur indique…
  - [^] # Re: ça ne résoudera pas ton problème
    
    Posté par fearan le 29 novembre 2022 à 11:02. Évalué à 3. Dernière modification le 29 novembre 2022 à 11:02.
    
    Dans le temps j'étais un peu plus bourrin et je copiais le cookie d'authentification (.Xauthority) depuis le home de l'user connecté vers l'autre. Je ne suis pas certain que ça soit une meilleur pratique et j'ai arreté.
    
    C'est plus secure que la manip xhost +, et c'est un poil plus bourrin que xauth list/xauth add ;)
    
    Mais crois moi en IUT c'était un risque de delog dans les minutes (xkill -id 0 ou un truc du genre), et en milieu pro, début avril, des poissons sont très vite arrivé. Mais au delà des poisson (c'est gentil), ce que tu risques c'est une écoute de ton clavier (xev par exemple) des capture d'écran, et des mouvements de souris.
    
    Il ne faut pas décorner les boeufs avant d'avoir semé le vent
    - [^] # Re: ça ne résoudera pas ton problème
      
      Posté par moi1392 le 29 novembre 2022 à 11:14. Évalué à 2.
      
      Vous êtes violent dans votre IUT… bon après j'ai une policy par défaut en drop sur les paquets tcp de connexion en entrée, c'est pour ça que je ne me gêne pas trop là dessus ;)
      Mais oui c'est un coup à le faire par réflexe un jour ou sur une machine où je serai moins safe, je vais m'efforcer de changer cette habitude, merci :)
      - [^] # Re: ça ne résoudera pas ton problème
        
        Posté par fearan le 29 novembre 2022 à 12:55. Évalué à 3.
        
        ça remonte à pas mal d'année où certaines machines étaient poussives; quelques machines DEC avaient mozilla, mais en lancer 2 sur une machine la faisaient ramer à mort.
        
        (on avait aussi d'autre machine des station alpha et des pc linux), mais certains faisaient un rlogin demeter (ou dionysos ou un autre) pour lancer le mozilla en export display… On ne lançait ce script que sur les machines poussives ou lorsque notre station ramait
        
        on avait donc fait un script du genre (de tête)
        
        while : do last -10 | grep -v $USER | while read user tty from next do export DISPLAY=${from}:0 xkill -id 0 done sleep 1 done
        
        y'avait aussi une vérification pour pas se viser soit même (teste sur l'ip et nom de machine), mais me souvient plus de ce qu'on avait fait précisément ; il est aussi probable qu'on ait utilisé awk plutôt que read
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.