Idea: parse argument list of kernels for safer launching
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
Piste de recherche
Commencez par examiner les points d’entrée proposés cust::module::Module, cust::function::Function et Stream, ainsi que les alternatives concernant le runtime et build.rs décrites dans l’issue. Le travail ne pourra être considéré comme terminé qu’une fois qu’une approche, son périmètre PTX/fatbin et les attentes en matière de validation auront été convenus.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
The combination of cuLaunch requiring getting the argument list exactly right and major version changes of PTX ISA can change the argument list makes it close to impossible of being certain that a kernel is launched correctly using the driver API. One way to improve upon this would be to parse the ptx/fatbin for kernel argument list and verify the rust source against it. This would not be possible for cubin, but ptx/fatbin should cover most use cases.
There are basically two approaches to this. The runtime approach would be to add function argument list info to Cust::module::Module which is generated when ptx/fatbin is added to the module. Then it would be passed to the cust::function::Function when it is created.
The other alternative is a static/build.rs alternative. We could create a dev-dependency that parses a .ptx and create rust types containing information about the argument list layout. A generic method on Module would then return the specific type implementing some Kernel trait and the Stream would have a generic launch function that would accept some <Function as Kernel>::ArgList argument.
I'm not promising to implement this, but would love to get some feedback on the idea.
- Langage dominant
- Rust
- Étoiles
- 5.4k
- Forks
- 251
- Merge moyen
- 4 j 15 h
- PR mergées (30 j)
- 4
Préparer son environnement
Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de Rust-GPU/rust-cuda
-
Default NvvmArch::Compute75 silently produces InvalidPtx on pre-Turing GPUs (Pascal/Maxwell/Volta)Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 30/100
-
Array parameters lose alignment metadata and ICE on >16 byte alignmentsPeut-être pris @Snehal-Reddy l’a pris il y a 163 jours. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
-
Support llvm-19 in containersOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 38/100
Toutes les issues de Rust-GPU/rust-cuda
Issues similaires
-
[Bug]:设置的关于页面，“系统信息”部分排版异常Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 63/100
metasequoiaime/msime#7328 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
eclipse-opensovd/classic-diagnostic-adapter#616 ·
Les mainteneurs répondent en général sous 2 jours
-
documentation
Difficulté 1/5 Moins d'une heure Accessibilité débutants 86/100
Les mainteneurs répondent en général sous 1 jour
-
track: content
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
0xAndersen/witness-log#10 ·
-
follow-up main-defect wave-A
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
carrick-sh/carrick#249 ·
Les mainteneurs répondent en général sous 1 jour