Ielāps, kas DirectX atbalstu LLVM kompilatorā pārcēla no eksperimentāla uz oficiālu, izdzēš vairāk rindu nekā pievieno: astoņi faili, 20 jaunas rindas un 32 noņemtas. Izmaiņu numur 214066 LLVM repozitorijā iekļāva 31. augustā. Autors ir Microsoft HLSL kompilatora inženieris Farzon Lotfi.
Tik maza izmaiņa iespējama tāpēc, ka kods jau bija vietā. Noņemts galvenokārt tas, kas DirectX aizmuguri turēja ārpus noklusētā būvējuma. No nākamā gada LLVM 24 laidiena parastā LLVM instalācijā būs DXIL ģenerators un komandrindas rīks clang-dxc, tāpēc šeideru autoram HLSL koda kompilēšanai vairs nevajadzēs Microsoft atsevišķo kompilatoru DXC.
ko maina statuss
LLVM aizmugures iedala divās kategorijās. Eksperimentālās nebūvē pēc noklusējuma; tās jāieslēdz ar CMake mainīgo LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. Oficiālās aizmugures būvē vienmēr. Uz tām attiecas arī citas prasības: izmaiņas LLVM vidusdaļā nedrīkst klusi salauzt aizmuguri, bet būvējuma bojājumi kļūst par visas kopienas problēmu.
Aizmugure mērķē uz DXIL, Microsoft starpvalodu DirectX 12 šeideriem. Mērķa virkne izskatās kā dxil-pc-shadermodel6.0-compute, kur pēdējā daļa nosauc konveijera posmu: compute, pixel, vertex vai library. LLVM dokumentācija min šeideru modeļus no 6.0 uz augšu. DirectX 11 atbalsts nav tuvākajos plānos.
Otrs jaunums ielāpā ir clang-dxc. Tas ir Clang draivera režīms, kas pieņem tās pašas komandrindas opcijas kā DXC, līdzīgi kā clang-cl atdarina Microsoft cl.exe. Esošu būvēšanas skriptu var pārslēgt uz jauno kompilatoru bez pārrakstīšanas, tikai nomainot izpildāmā faila nosaukumu. Izvade ir DXContainer fails ar iegultu bitkodu; mehānisms atgādina Clang -fembed-bitcode karodziņu.
kāpēc Microsoft pārcēlās uz augšupstraumi
Ražošanā Microsoft joprojām izmanto DXC. Tas ir LLVM/Clang 3.7 atzarojums, kura publiskais repozitorijs GitHub parādījās 2016. gada decembrī. Kompilators darbojas, taču tas ir iesaldēts kompilatora tehnoloģijās, kas vecākas par desmit gadiem.
2022. gada 8. martā LLVM forumā Chris Bieneman publicēja priekšlikumu HLSL un DirectX atbalstu ienest tieši LLVM. Iemesls bija tiešs: 3.7 atzarojums nesaņem jaunos C++ valodas un rīku uzlabojumus, kurus HLSL izstrādātāji prasa. Vecā atzarojuma iesūtīšana augšupstraumē nebija reāla, tāpēc komanda sāka funkcionalitāti rakstīt no jauna pa daļām. Kopā tas prasīja četrus gadus.
Iesaldētais bitkoda formāts ir tas, kas šo aizmuguri atšķir no pārējām. Draiveri sagaida tieši LLVM 3.7 laika bitkodu ar noteiktu metadatu shēmu, tāpēc mūsdienu LLVM nevar vienkārši izmest savu parasto IR. Starp optimizētāju un izvadi stāv atsevišķa kārta, kas konstrukcijas pārtulko atpakaļ vecākā formā. Tāpēc arī jebkura izmaiņa LLVM bitkoda rakstītājā var negaidīti aizskart DirectX aizmuguri.
ko aizmugure prot šodien
Skaitļošanas šeideri sasniedz DXC līmeni. Grafikas un staru izsekošanas šeideri vēl nē. Aizmugurei ir sava legalizācijas kārta ar pielāgotām IR transformācijas caurlaidēm plus konformitātes testu kopa, kas balstās uz LLVM standarta testu infrastruktūru.
Farzon Lotfi priekšlikuma pavedienā aprakstīja nākamos soļus:
Turpmāk mūsu uzmanība pārvirzīsies uz grafikas un staru izsekošanas šeideru atbalstu, jaunākajiem šeideru modeļiem un ciešāku sasaisti starp Clang HLSL priekšgalu un aizmugures koda ģenerēšanu.
Loģika ir vienkārša. Kamēr aizmugure bija eksperimentāla, to izmēģināja tikai tie, kas paši būvē LLVM ar īpašiem karodziņiem. Ar noklusēti ieslēgtu clang-dxc kļūdu ziņojumi sāks nākt no cilvēkiem, kuri raksta īstus šeiderus.
kas apspriešanā izteica iebildumus
Apstiprināšana notika ar piezīmēm. Izstrādātājs ar segvārdu jmorse jautāja par atkļūdošanas informāciju: DXIL bitkods paliek iesaldēts LLVM 3.7 formātā, tāpēc mūsdienu LLVM atkļūdošanas metadati tajā tieši neiederas. Nikita Popov gribēja skaidrību, cik daudz aizmugure ietekmē LLVM vidusdaļu, kā arī par structured.gep statusu. Matt Arsenault priekšlikumu atbalstīja, vienlaikus kritizējot eksperimentālo aizmuguru praksi kopumā. Chris Bieneman atbildēja, ka šie jautājumi tiks risināti pašā aizmugurē.
Uzturēšanas slogu autori novērtēja kā nelielu. Būvējuma lūzumi, ko izraisījušas izmaiņas LLVM vidusdaļā, līdz šim prasījuši dažu rindu labojumus. Komanda apņēmās pret DXIL bitkoda izmaiņām attiekties tāpat kā citas aizmugures: labojumus veic izmaiņu autori.
LLVM apgabalu komanda priekšlikumu apstiprināja 20. augustā. Nikita Popov atbilde bija divi vārdi: “Ship it!”
kāpēc tas skar arī Vulkan pusi
HLSL kompilēšana neaprobežojas ar Windows. Khronos glslang HLSL priekšgals 2026. gada aprīlī pasludināts par novecojušu, tā izņemšana gaidāma nākamajā lielajā versijā ar vismaz 18 mēnešu brīdinājumu. Vienlaikus Microsoft ir paziņojis, ka DirectX nākotnes apmaiņas formāts būs SPIR-V.
Praktiski tas nozīmē, ka HLSL kompilēšana uz Vulkan mērķiem arvien vairāk notiks caur Clang plus LLVM SPIR-V aizmuguri. Tā pati HLSL priekšgala infrastruktūra Clang iekšienē apkalpo abus izvades formātus. Linux spēļu izstrādātājam tas ir tuvāk ierastajai rīkkopai nekā atsevišķs Microsoft kompilators ar savu būvēšanas sistēmu un savu laidienu grafiku.
Uzdevums, kas prasīja panākt vienošanos par pārcelšanu, HLSL darba grupas repozitorijā bija atvērts no 23. jūlija līdz 31. augustam. Izmaiņa jau ir LLVM galvenajā zarā. Laidienā tā nonāks ar LLVM 24 nākamgad.
Avoti
- Phoronix: DirectX Support Promoted To Official Target Within LLVM
- llvm-project PR #214066: [DirectX] Promote to an official target
- LLVM Discourse: RFC Promoting the DirectX Backend to an Official Target
- LLVM Discourse: RFC Adding HLSL and DirectX support to Clang & LLVM
- LLVM: User Guide for the DirectX Target
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.