Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Impact of removal of explicit queues

Aperta
  • Qualcosa non va?
#322 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
documentation

Direzione di ricerca

Inizia esaminando i commit 44df8eb76bfc1bbf10c683611ac381a2ca80e8cf e 9f2dd09a33bbe27af3a64452cf8fc109f8948568, la discussione in #321 e la sezione sulla coda dei comandi di PROG.md. Determina le implicazioni previste per queue indices, numQueues e queue groups, quindi aggiorna le dichiarazioni della specifica interessate una volta deciso tale comportamento.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

I'd appreciate clarification on the implications of the changes in 44df8eb76bfc1bbf10c683611ac381a2ca80e8cf and 9f2dd09a33bbe27af3a64452cf8fc109f8948568 (triggered by the discussion in #321),

As part of that change, it seems like other parts of the spec should also be updated, such as the following statement, which I think now doesn't make sense any more:

The command queue index provides a mechanism for an application to indicate which command queues can execute concurrently (different indices).

Because now that all queue indices must be 0, there cannot be different indices, so I guess the statement should just be removed as well.

The same reasoning applies to more statements in the command queue section, I think basically everything that talks about command queue indices (as they're now all equal to 0 by definition). It seems the index attribute now just exists for backwards compatibility reasons and could otherwise just be removed entirely.

Regarding the further implications of the removal of explicit queues: to my understanding, explicit queues were the mechanism that Level Zero provided to allow fine-grained use of multiple physical engines in a queue group. Let me give an example:

  • Let's assume my Level Zero device has a DMA unit with 4 channels, i.e., it can handle 4 parallel transfers independently.
  • So far, I could expose this DMA unit as a queue group queueGroup with only COPY capability and 4 physical engines, i.e., queueGroup.numQueues == 4.
  • If I wanted a transfer to happen on a specific channel, I could create an explicit queue with the appropriate index (0 for the first channel, 1 for the second channel, etc.) and then copy commands submitted to that queue would only execute on the appropriate channel.
  • If I didn't care about the channel, I could create a non-explicit queue and let the implementation pick one (likely just one that is free).

So now that the concept of explicit command queues was removed, what purpose does the numQueues attribute of a queue group have? It seems like it's entirely useless and can be removed as well or must at least be forced to 1, to keep the attribute itself around. Or am I mistaken?

And going further, once numQueues is gone or always forced to 1, isn't also the whole concept of a queue group moot? Because it seems you cannot really do a lot with them now that explicit queues are gone.

As a side remark: while playing around with Intel's Level Zero implementation for GPUs on my machine, I did notice that it makes no usage of those concepts at all and just exposes one queue group with capability COMPUTE | COPY and 1 physical engine, which is the degenerate case where the whole queue group concept wouldn't be needed. It would be interesting to know if there's another implementation that makes actual use of these concepts or whether you planned to remove them anyway from the spec.

Lingua principale
Python
Stelle
19
Fork
29
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di oneapi-src/level-zero-spec

Tutte le issue di oneapi-src/level-zero-spec

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.