หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด

SPIR-?

? ?เป้าหมาย ? ? แรนฟอร์ม ? ?แปล ⋯?

สไปร์-? เป็นโครงการวิจัยที่มุ่งสำรวจการออกแบบ IR ที่เน้นเชเดอร์ซึ่งได้มาจาก SPIR-V และสร้างกรอบงานเกี่ยวกับ IR ดังกล่าวเพื่ออำนวยความสะดวกในการคอมไพล์ไปป์ไลน์ขั้นสูง นอกเหนือจากที่เครื่องมือ SPIR-V ที่มีอยู่อนุญาต

ความต้องการดังกล่าวเกิดขึ้นในโครงการ Rust-GPU ซึ่งต้องใช้การผ่านการรับรองที่หลากหลายเพื่อเปลี่ยนโค้ดที่ใช้งานทั่วไป (Rust 1 ) ที่ทำงานบนหน่วยความจำ ที่ไม่ได้พิมพ์ ให้เป็นโฟลว์ข้อมูลโดยตรงที่เป็นมิตรกับ GPU
เป้าหมายของเราคือการแทนที่การผ่านการรับรองความถูกต้องตามกฎหมายของ Rust-GPU SPIR-V ที่มีอยู่ด้วย SPIR-? เทียบเท่า - แต่ที่สำคัญยิ่งกว่านั้น SPIR-? ควรอนุญาตให้เขียนผ่านการรับรองความถูกต้องตามกฎหมาย / การเพิ่มประสิทธิภาพที่มีประสิทธิภาพมากขึ้นซึ่งเป็นสิ่งที่ไม่อาจหยั่งรู้ได้ 2 สำหรับการจัดการ SPIR-V โดยตรง

1 Rust ไม่ได้มีลักษณะเฉพาะในความต้องการที่นี่ และในที่สุดภาษา (หรือ IR) ก็สามารถใช้ประโยชน์จากเฟรมเวิร์กดังกล่าวได้ในที่สุด แต่งานออกแบบเบื้องต้นและการใช้งานมุ่งเน้นไปที่ Rust-GPU

2 ไม่ใช่ว่าเป็นไปไม่ได้เลย แต่ต้องใช้ต้นทุนการพัฒนา/การบำรุงรักษาที่มากเกินไป โดยต้องรักษาสมดุลระหว่างความถูกต้องและกำลังอย่างต่อเนื่อง (การส่งผ่านแบบอนุรักษ์นิยมมากกว่าจะเชื่อถือได้ง่ายกว่า) เป็นต้น

ข้อสงวนสิทธิ์

โครงการนี้ไม่มีส่วนเกี่ยวข้อง เกี่ยวข้อง ได้รับอนุญาต รับรองโดย หรือเกี่ยวข้องอย่างเป็นทางการในทางใดทางหนึ่งกับ Khronos Group Inc. หรือบริษัทสาขาหรือบริษัทในเครือใดๆ สามารถดูเว็บไซต์ทางการของ Khronos Group Inc. ได้ที่ https://www.khronos.org
ชื่อ SPIR, SPIR-V รวมถึงชื่อ เครื่องหมาย ตราสัญลักษณ์ และรูปภาพที่เกี่ยวข้อง เป็นเครื่องหมายการค้าของเจ้าของที่เกี่ยวข้อง

บริบทเพิ่มเติม: ชื่อของโครงการนี้เป็นการเล่นสำนวนบน SPIR-V และไม่เกี่ยวข้องกับ SPIR เลย (มาตรฐาน IR แบบเก่า)

สถานะ

- โครงการนี้อยู่ระหว่างการออกแบบและพัฒนา รายละเอียดมากมายสามารถและจะเปลี่ยนแปลง ?

หากคุณสนใจที่จะใช้ SPIR-? ตัวคุณเอง คุณอาจต้องการดูตัวติดตามปัญหาสำหรับปัญหาที่เกี่ยวข้องก่อน และแม้แต่เปิดอันใหม่ที่อธิบายกรณีการใช้งานของคุณ
ด้วยการมุ่งเน้นไปที่กรณีการใช้งานของ Rust-GPU ในตอนแรก ฟังก์ชัน/API/เอกสารต่างๆ (ที่เป็นที่ต้องการ) อาจขาดหายไป หรือมีการเปลี่ยนแปลงอย่างรวดเร็ว ในเวลาเดียวกัน การอภิปรายเกี่ยวกับการขยายขอบเขตและการใช้งานของ SPIR-? ในระยะยาว ก็ยังยินดีต้อนรับ

ไม่ใช่เป้าหมาย (อย่างน้อยในระยะสั้น)

  • รองรับภาษา Kernel ("OpenCL") ของ SPIR-V
    • Kernel SPIR-V นั้นใกล้กับ LLVM IR มากกว่า Shader SPIR-V มากและเนื่องจากเครื่องมือดังกล่าวที่เน้นไปที่ LLVM จึงมีแนวโน้มที่จะเหมาะสมกว่า
  • ไวยากรณ์ข้อความที่สามารถแยกวิเคราะห์กลับได้
    • กล่าวคือเอาต์พุตของพริตเตอร์พรินเตอร์เป็นเพียงการแสดงภาพเท่านั้น

ออกแบบและดำเนินการจนถึงปัจจุบัน

ประเภทข้อมูล IR :

  • อนุญาตคำสั่ง SPIR-V ที่เกือบจะไร้เหตุผลสำหรับ opcodes ที่ไม่รู้จัก
    • รหัสจะถูกแทนที่ด้วยหมายเลขอ้างอิงภายใน/"เอนทิตี" (ดูด้านล่าง)
  • การฝึกงานด้านคุณลักษณะ (ของตกแต่งและสิ่งที่คล้ายกัน) ประเภท และค่าคงที่
    • เช่น การขจัดข้อมูลซ้ำซ้อนอัตโนมัติ การจัดทำดัชนีที่มีประสิทธิภาพ และไม่มีแนวคิดเรื่อง "คำจำกัดความ" (เฉพาะการใช้หมายเลขอ้างอิงภายในเท่านั้นที่สามารถนำไปสู่โมดูลที่พิจารณาว่ามีประเภท/ค่าคงที่เฉพาะ)
  • ระบบ "เอนทิตี" เช่น คำจำกัดความในโมดูล คำสั่งในฟังก์ชัน ฯลฯ
    • ไม่อนุญาตให้ทำซ้ำเพื่อสนับสนุน/บังคับให้ใช้การจัดทำดัชนีที่มีประสิทธิภาพ
  • "ภูมิภาค" ของโฟลว์การควบคุมที่มีโครงสร้างซึ่งได้รับแรงบันดาลใจจาก RVSDG เข้มงวดกว่า SPIR-V (ดูเอกสารของ ControlRegionDef สำหรับรายละเอียดเพิ่มเติม)

ยูทิลิตี้กรอบ :

  • visit / transform : การแวะผ่าน IR ที่ไม่เปลี่ยนรูป/ไม่แน่นอน
  • print : Pretty-printer พร้อมเอาต์พุต HTML (มีสไตล์และไฮเปอร์ลิงก์)

ผ่าน (ไป/จาก/บน SPIR-?) :

  • spv::lower : "ลดระดับ" จาก SPIR-V ทำให้รายละเอียดที่ไม่เกี่ยวข้องหลายอย่างเป็นปกติ
    • สูญเสียรายละเอียดที่เกี่ยวข้องบางส่วน (นี่คือข้อบกพร่อง แม้ว่าหลายรายการจะไม่มีความหมายดังนั้นจึงมีลำดับความสำคัญต่ำกว่า)
  • spv::lift : "การยก" สำรองไปที่ SPIR-V โดยทำการเลือกตามอำเภอใจตามความจำเป็น
    • เทียบได้กับเช่นการสร้างไวยากรณ์ GLSL จาก SPIR-V เพียงระดับเดียวเท่านั้น
  • cfg::Structurizer : (ใหม่) โครงสร้างจากโฟลว์การควบคุมโดยพลการไปจนถึง "ภูมิภาค" ที่มีโครงสร้างที่เข้มงวดยิ่งขึ้น
  • passes::link : การแมป (การเชื่อมโยง) นำเข้าไปยังการส่งออกที่เกี่ยวข้อง

ตัวอย่างง่ายๆ (พร้อมโฟลว์การควบคุมที่ไม่สำคัญ)

GLSL ( for-loop.vert.glsl ) 

 #version 450
out int output0;
void main() {
    int o = 1 ;
    for ( int i = 1 ; i < 10 ; i ++ )
    	  o *= i;
    output0 = o;
}

WGSL ( for-loop.wgsl ) 

@vertex
fn main() -> @location( 0 ) i32 {
    var o : i32 = 1 ;
    for (var i : i32 = 1 ; i < 10 ; i ++ ) {
    	o *= i;
    }
    return o;
}

สไปร์-? 

#[spv.Decoration.Flat]
#[spv.Decoration.Location(Location: 0 )]
global_var GV0 in spv.StorageClass.Output: s32

func F0 () -> spv.OpTypeVoid {
  loop (v0: s32 <- 1s32, v1: s32 <- 1s32) {
    v2 = spv. OpSLessThan (v1, 10s32): bool
    (v3: s32, v4: s32) = if v2 {
      v5 = spv. OpIMul (v0, v1): s32
      v6 = spv. OpIAdd (v1, 1s32): s32
      (v5, v6)
    } else {
      (spv. OpUndef : s32, spv. OpUndef : s32)
    }
    (v3, v4) -> (v0, v1)
  } while v2
  spv. OpStore (Pointer: &GV0, Object: v0)
}

SPIR-V ( for-loop.wgsl.spvasm ) 

 %typeof_output0 = OpTypePointer Output %i32
%output0 = OpVariable %typeof_output0 Output

%typeof_main = OpTypeFunction %void
%main = OpFunction %void None %typeof_main
  %entry = OpLabel
    OpBranch %bb0
  %bb0 = OpLabel
    OpBranch %bb1
  %bb1 = OpLabel
    %o = OpPhi %i32 %1 _i32 %bb0 %o_next %bb5
    %i = OpPhi %i32 %0 _i32 %bb0 %i_next %bb5
    OpLoopMerge %bb6 %bb5 None
    OpBranch %bb2
  %bb2 = OpLabel
    %cond = OpSLessThan %bool %i %10 _i32
    OpSelectionMerge %bb4 None
  OpBranchConditional %cond %bb4 %bb3
  %bb3 = OpLabel
    OpBranch %bb6
  %bb4 = OpLabel
    %o_next = OpIMul %i32 %o %i
    OpBranch %bb5
  %bb5 = OpLabel
    %i_next = OpIAdd %i32 %i %1 _i32
    OpBranch %bb1
  %bb6 = OpLabel
    OpStore %output0 %o
    OpReturn
OpFunctionEnd

ภาพรวมแนวนอน IR ของ GPU (เชเดอร์)

(และวิสัยทัศน์ว่า SPIR-? เข้ากับมันได้อย่างไร)

ความแตกต่างที่เกิดขึ้นที่นี่คือระหว่าง:

  • Interchange IRs (มาตรฐานที่เครื่องมือจำนวนมากสามารถใช้เพื่อทำงานร่วมกันได้)
    • SPIR-V มีจุดมุ่งหมายอย่างมากให้เป็นมาตรฐานดังกล่าว (นอกพื้นที่ GPU แล้ว wasm ก็เป็นตัวอย่างที่ดีเช่นกัน)
    • พวกเขาเพียงต้องเข้ารหัสแนวคิดที่ถูกต้อง โดยไม่หลงไปจากสิ่งที่เครื่องมือเข้าใจมากนัก แต่ความพยายามในการออกแบบมักจะมุ่งเน้นไปที่รูปแบบ "การทำให้เป็นอนุกรม"
  • Compiler IRs (รายละเอียดการใช้งานที่ไม่ได้มาตรฐานของคอมไพเลอร์)
    • LLVM ค่อนข้างเป็นที่รู้จัก แต่ NIR ของ Mesa นั้นใกล้เคียงกับ SPIR-? (ทั้งเป็นแบบเน้นเชเดอร์ และมีตัวเลือกพิเศษที่คล้ายกัน เช่น การจัดการโฟลว์ควบคุม)
    • สิ่งเหล่านี้ ต้อง จัดการกับการทำให้ถูกต้องตามกฎหมาย/การเพิ่มประสิทธิภาพให้ผ่านไปได้ค่อนข้างดี และโดยทั่วไปแล้ว การเปลี่ยนแปลงจำนวนมากแบบทันที เนื่องจากจุดประสงค์หลักคือ การเร่ง การดำเนินการดังกล่าว
    • นี่คือที่ SPIR-? นั่งในฐานะ "ญาติ" / ภาษาถิ่นของ SPIR-V แต่ทำการแลกเปลี่ยนเพื่อสนับสนุนการใช้งาน "คอมไพเลอร์ภายใน"

ผลงาน

เรายินดีรับการสนับสนุนจากชุมชนในโครงการนี้

โปรดอ่านคู่มือผู้ร่วมให้ข้อมูลของเราเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีเริ่มต้นใช้งาน โปรดอ่านข้อกำหนดผู้ร่วมให้ข้อมูลของเราก่อนที่คุณจะมีส่วนร่วมใดๆ

การสนับสนุนใดๆ ที่ส่งโดยเจตนาเพื่อรวมไว้ในโครงการ Embark Studios จะต้องเป็นไปตามรูปแบบใบอนุญาตมาตรฐานของ Rust (MIT หรือ Apache 2.0) และดังนั้นจึงได้รับใบอนุญาตแบบคู่ตามที่อธิบายไว้ด้านล่าง โดยไม่มีข้อกำหนดหรือเงื่อนไขเพิ่มเติมใด ๆ:

ใบอนุญาต

การบริจาคนี้ได้รับอนุญาตแบบคู่ภายใต้อย่างใดอย่างหนึ่ง

  • Apache License เวอร์ชัน 2.0 (LICENSE-APACHE หรือ http://www.apache.org/licenses/LICENSE-2.0)
  • ใบอนุญาต MIT (LICENSE-MIT หรือ http://opensource.org/licenses/MIT)

ตามตัวเลือกของคุณ

เพื่อความชัดเจน "ของคุณ" หมายถึง Embark หรือผู้รับอนุญาต/ผู้ใช้รายอื่นในผลงาน

ขยาย
ข้อมูลเพิ่มเติม
แอปที่เกี่ยวข้อง
แนะนำสำหรับคุณ
ข้อมูลที่เกี่ยวข้อง ทั้งหมด