Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Impact of removal of explicit queues

Offen
  • Stimmt etwas nicht?
#322 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
20/100
Issue-Typ
Dokumentation
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Bereich
documentation

Rechercherichtung

Beginne mit der Durchsicht der Commits 44df8eb76bfc1bbf10c683611ac381a2ca80e8cf und 9f2dd09a33bbe27af3a64452cf8fc109f8948568, der Diskussion in #321 und des Abschnitts zur Befehlswarteschlange in PROG.md. Bestimme die beabsichtigten Auswirkungen auf queue indices, numQueues und queue groups, und aktualisiere die betroffenen Spezifikationsaussagen, sobald dieses Verhalten festgelegt ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
19
Forks
29
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus oneapi-src/level-zero-spec

Alle Issues in oneapi-src/level-zero-spec

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.