คำถามติดแท็ก performance

3
ตัวประมวลผลที่มีประสิทธิภาพสูงกว่าตัวกรองพิกเซลสำหรับการกรองภาพเมื่อใด
การดำเนินการกรองภาพเช่น blurs, SSAO, บลูมและอื่น ๆ มักจะทำโดยใช้ shaders พิกเซลและการดำเนินการ "รวบรวม" โดยที่การเรียกพิกเซล shader แต่ละครั้งจะมีปัญหาจำนวนเนื้อเรียกเพื่อเข้าถึงค่าพิกเซลที่อยู่ใกล้เคียงและคำนวณมูลค่าพิกเซลเดียว ผลลัพธ์. วิธีการนี้มีความไร้ประสิทธิภาพทางทฤษฎีในการดึงข้อมูลซ้ำซ้อนจำนวนมาก: การเรียกใช้ shader ที่อยู่ใกล้เคียงจะดึงข้อความเดียวกันซ้ำหลาย ๆ ข้อความ อีกวิธีที่จะทำคือการคำนวณด้วยเฉดสี สิ่งเหล่านี้มีข้อได้เปรียบที่เป็นไปได้ในการแบ่งปันหน่วยความจำจำนวนเล็กน้อยในกลุ่มการเรียกใช้ shader ตัวอย่างเช่นคุณสามารถให้แต่ละการเรียกใช้หนึ่ง Texel และเก็บไว้ในหน่วยความจำที่ใช้ร่วมกันจากนั้นคำนวณผลลัพธ์จากที่นั่น นี่อาจจะเร็วกว่าหรือไม่ก็ได้ คำถามอยู่ภายใต้สถานการณ์ใด (ถ้าเคย) เป็นวิธีการคำนวณ - shader จริงเร็วกว่าวิธีพิกเซล -shader? มันขึ้นอยู่กับขนาดของเคอร์เนลการดำเนินการกรองแบบไหน ฯลฯ เห็นได้ชัดว่าคำตอบจะแตกต่างจาก GPU รุ่นหนึ่งไปยังอีกรุ่นหนึ่ง แต่ฉันสนใจที่จะได้ยินหากมีแนวโน้มทั่วไป

2
ค่าใช้จ่ายในการเปลี่ยนสถานะคืออะไร?
โปรแกรมเมอร์ควรมีความคิดที่ดีเกี่ยวกับค่าใช้จ่ายของการดำเนินการบางอย่างเช่นค่าใช้จ่ายในการเรียนการสอนบน CPU, ค่าใช้จ่ายของ L1, L2, หรือ L3 Cache, ค่า LHS เมื่อพูดถึงกราฟิกฉันรู้ว่าฉันไม่รู้ตัวเลยว่ามันคืออะไร ฉันมีในใจว่าถ้าเราสั่งพวกเขาโดยค่าใช้จ่ายการเปลี่ยนแปลงสถานะเป็นดังนี้ การเปลี่ยนเครื่องแบบของ Shader การเปลี่ยนแปลงบัฟเฟอร์จุดสุดยอดที่ใช้งานอยู่ การเปลี่ยนแปลงหน่วยพื้นผิวที่ใช้งานอยู่ การเปลี่ยนแปลงโปรแกรม shader ที่ใช้งานอยู่ การเปลี่ยนบัฟเฟอร์เฟรมที่แอ็คทีฟ แต่นั่นเป็นกฎง่ายๆที่อาจจะไม่ถูกต้องและฉันก็ไม่รู้ว่าคำสั่งของขนาดนั้นคืออะไร หากเราพยายามใส่หน่วย, ns, รอบสัญญาณนาฬิกาหรือจำนวนคำสั่งเราพูดถึงเท่าไหร่?

3
ประสิทธิภาพของกราฟิกแบบเวกเตอร์เทียบกับบิตแมปหรือกราฟิกแรสเตอร์
บางครั้งฉันใช้กราฟิกแบบเวกเตอร์เพียงเพราะพวกเขาดูดีกว่าเล็กน้อยในบางกรณีและบางครั้งฉันก็ใช้กราฟิกบิตแมป / แรสเตอร์ ฉันสงสัยว่ามีตัวเลือกประสิทธิภาพแตกต่างกันระหว่างสองตัวเลือกเหล่านี้หรือไม่

1
ทำไมเงื่อนไขนี้ในส่วนย่อยของฉันจึงช้า
ฉันได้ตั้งค่ารหัสการวัด FPS บางอย่างใน WebGL (ตามคำตอบ SO นี้ ) และได้ค้นพบความแปลกประหลาดบางอย่างกับประสิทธิภาพของชิ้นส่วนของฉัน รหัสนี้แสดงเพียงรูปสี่เหลี่ยมจัตุรัสเดียว (หรือมากกว่าสองรูปสามเหลี่ยม) บนผืนผ้าใบขนาด 1024x1024 ดังนั้นเวทมนตร์ทั้งหมดจึงเกิดขึ้นในส่วนย่อย พิจารณา shader ง่าย ๆ นี้ (GLSL; vertex shader เป็นเพียงแค่ pass-through): // some definitions void main() { float seed = uSeed; float x = vPos.x; float y = vPos.y; float value = 1.0; // Nothing to see …

3
เหตุใดเราจึงมีกรอบกราฟิกเช่น OpenGL และ DirectX เมื่อเกมสามารถวาดพิกเซลได้โดยตรง
เกมและแอพพลิเคชั่นที่เน้นกราฟิกอื่น ๆ ใช้เฟรมเวิร์กเช่น OpenGL และ DirectX พวกมันต้องการคุณสมบัติเช่น pixel shader และ DX12 แต่ทำไมเราต้องใช้เฟรมเวิร์กและฟีเจอร์ GPU ทั้งหมดเมื่อเราสามารถวาดทุก ๆ พิกเซลทีละพิกเซลได้? ขั้นแรกเกมจะต้องรวบรวมในลักษณะดังนั้นจึงถูกวาดพิกเซลโดยพิกเซล สิ่งนี้มีแนวโน้มที่จะทำให้เกมใช้งานได้ดี แต่จะเร็วกว่าและทำงานกับ GPU สี 32 บิตใด ๆ (แม้กระทั่งเก่า) ฉันรู้ว่าเกม 3 มิติแรกถูกวาดทีละพิกเซล แต่ทำไมพวกเขาถึงไม่ทำในตอนนี้

3
ความแตกต่างระหว่างการแสดงผลในซอฟต์แวร์ OpenGL และภาพเคลื่อนไหว 3 มิติ
ด้วย OpenGL และฉันสามารถทำให้สิ่งที่ดูน่าทึ่งใน "เรียลไทม์" 60 FPS อย่างไรก็ตามถ้าฉันพยายามสร้างวิดีโอของฉากเดียวกันในสมมติว่า Maya หรือ 3ds Max มันจะใช้เวลานานมากในการแสดงผลแม้ว่ามันจะเป็นความละเอียดและ FPS เดียวกันก็ตาม ทำไมการเรนเดอร์ทั้งสองประเภทนี้จึงใช้ช่วงเวลาต่างกันสำหรับผลลัพธ์เดียวกัน หมายเหตุ: ใช่ฉันตระหนักดีว่าซอฟต์แวร์แอนิเมชั่นสามมิติสามารถสร้างภาพที่ยอดเยี่ยมสูงถึงสิ่งที่สามารถทำได้ตามเวลาจริง แต่สำหรับคำถามนี้ฉันหมายถึงฉากที่มีความซับซ้อนเท่ากัน

1
เงื่อนไขคงที่มีราคาแพงกว่าการเปลี่ยนเครื่องแต่ง
โดยทั่วไปแล้วการแตกแขนงในร่มเงาไม่ใช่ความคิดที่ดี แต่ตอนนี้ฉันมี shader ที่มีเงื่อนไขที่คงที่เกี่ยวกับการเรียกการดึงทั้งหมด ดังนั้นสาขาที่ดำเนินการจะเป็นแบบเดียวกันเสมอสำหรับการโทรแบบดึงครั้งเดียว การแตกแขนงแบบนี้ยังมีค่าใช้จ่ายสูงกว่าการมีหลายเฉดสีที่ไม่มีกิ่งเหล่านี้และสลับไปมาระหว่างกันหรือไม่?

1
เมื่อใดจึงจะปิดใช้งานการแก้ไขมุมมองที่ถูกต้อง (ไม่มีตัวเลือก)
ใน GLSL มุมมองการแก้ไขที่ถูกต้องของยอดแอตทริบิวต์เป็นค่าเริ่มต้น - หนึ่งสามารถปิดการใช้งานที่เฉพาะเจาะจงสำหรับจุดสุดยอดแอตทริบิวต์โดยใช้noperspectiveรอบคัดเลือก นอกเหนือจากการใช้โพสต์โปรเซสซิ่งฉันไม่เคยเห็นมุมมองการแก้ไขที่ถูกต้องถูกปิดใช้งาน - มีกรณีการใช้งานอื่นอีกหรือไม่? นอกจากนี้มันยังสร้างความแตกต่างให้เกิดประสิทธิภาพ

1
ประสิทธิภาพการวนซ้ำในเครื่อง Shader
ฉันสงสัยว่าอะไรคือวิธีที่ดีที่สุดในการรวมฟังก์ชั่นวนลูปแบบไดนามิกเข้ากับ shader? ครั้งแรกดูเหมือนว่าไม่สามารถใช้อาร์เรย์แบบไดนามิกได้ ดังนั้นจะดีกว่าหรือไม่ที่จะสร้างอาร์เรย์ขนาดสูงสุดและเติมเพียงบางส่วนหรือกำหนดอาร์เรย์ด้วยขนาดที่กำหนดไว้ล่วงหน้า แล้ววิธีที่ดีที่สุดในการทำซ้ำแถวลำดับนี้คืออะไร ควรใช้ลูปที่ไม่ได้ควบคุมหรือลูปไดนามิกสำหรับบางอย่างระหว่างการทำซ้ำ 4 ถึง 128 หรือไม่ if (i == myCurrentMaximumIterationNumber)ผมเคยเห็นยังว่ามันเป็นไปได้ที่จะคายมันจำนวนสูงสุดที่กำหนดไว้ล่วงหน้าซ้ำแล้วหยุดมันด้วยสภาพเช่น

1
เหตุใดการเข้าถึงพื้นผิวจึงช้าลงมากเมื่อคำนวณพิกัดพื้นผิวในส่วนของส่วน
เมื่อใช้พื้นผิวใน GLSL วิธีที่ดีที่สุดคือการคำนวณพิกัดพื้นผิวสุดท้ายใน shader ที่จุดสุดยอดและส่งให้กับ shader ของชิ้นส่วนโดยใช้varyings ตัวอย่างที่มีการพลิกง่าย ๆ ในพิกัด y: // Vertex shader attribute vec2 texture; varying highp vec2 texCoord; // ... void main() { texCoord = vec2(texture.x, 1.0-texture.y); // ... } // Fragment shader varying highp vec2 textureCoordinates; uniform sampler2D tex; // ... void main() { highp vec4 …

1
ทำไม AMD ถึงใส่ SSD ลงบนบอร์ด GPU เพื่อลดความล่าช้า
เมื่อไม่นานมานี้ AMD ได้มีข่าวกับบอร์ด Radeon Pro ที่น่าสนใจซึ่งมี M2 SSD อยู่สองตัว ตามที่มีรายละเอียดเพิ่มเติม (เช่นที่นี่หรือที่นี่ ) หมายเหตุประโยชน์ส่วนใหญ่อาจไม่ได้เกิดจากแบนด์วิดท์สูง (M2 นั้นอยู่ที่ PCIe 4 เลนต่อกันดังนั้นตัวเชื่อมต่อ 16 เลนของบอร์ดควรมีมากกว่า) จากเวลาแฝงต่ำ เรื่องนี้รวมถึงการอ้างสิทธิ์ "ผลลัพธ์นี้มีความล่าช้าในการเข้าถึงหน่วยความจำต่ำกว่า 10x" คำถามของฉันคือ: ทำไม SSD ที่เชื่อมต่อ PCIe บนบอร์ด GPU ควรมีความหน่วงแฝงน้อยกว่า GPU ที่เข้าถึง RAM ระบบหลักหรืออุปกรณ์เก็บข้อมูลบนบัส PCIe ระบบหรือไม่ มันเกี่ยวกับระบบหลักอะไรที่ "เข้ามาขวางทาง" และหมายความว่า SSD ของออนบอร์ดสามารถเข้าถึงได้เร็วกว่ามาก?

2
เมื่อใช้การเติมแบบใหม่และการเรนเดอร์ที่ทันสมัย
ตัวอย่างเช่นในขณะที่มันเป็น GPU อันดับต้น ๆ ของสายการผลิตนั้น GTX 980 มีอัตราการเติม 72.1 กิกะบิตต่อวินาทีที่สองซึ่งมีการเรนเดอร์กลับไปด้านหน้าและ / หรือการตรวจสอบบัฟเฟอร์ Z ดูเหมือนว่ามีขนาดใหญ่เกือบน่าขัน ที่ความละเอียด 4k เท่าที่โพลิกอนนับไป GPU สมัยใหม่สามารถทำรูปสามเหลี่ยมพื้นผิวได้หลายสิบถึงหลายร้อยล้านชิ้นโดยไม่มีการผูกปมหากคุณแบทช์และ / หรือสร้างอินสแตนซ์ให้ถูกต้อง ด้วยการเรนเดอร์เรนเดอร์ปริมาณของชิ้นส่วนที่ shaders จะทำงานจะสามารถครอบงำได้อย่างรวดเร็ว แต่ด้วยการเรนเดอร์ที่เลื่อนออกไปค่าใช้จ่ายมักจะคงที่มากหรือน้อยขึ้นอยู่กับความละเอียดและเราตั้งนาน เอฟเฟกต์หลังการประมวลผลสามารถทำได้แบบเรียลไทม์ใน 1080p ไม่ว่าจะด้วยวิธีใดปัจจัยที่ จำกัด ในปัจจุบันส่วนใหญ่คือการนับจำนวนการโทรและค่าใช้จ่ายในการแรเงาซึ่งทั้งสองอย่างนั้นยังคงอยู่ในระดับต่ำโดยการเรนเดอร์ที่เหมาะสมและการแบทช์ทางเรขาคณิต รูปหลายเหลี่ยม frustrum ของผลประโยชน์ที่สำคัญใด ๆ ? ค่าใช้จ่าย (เวลา CPU / GPU, เวลาโปรแกรมเมอร์) จะไม่มากไปกว่าประโยชน์ที่ได้รับจำนวนมากใช่ไหม

3
เหตุใด Vertex Buffer Objects จึงปรับปรุงประสิทธิภาพ
จากความเข้าใจพื้นฐานของฉัน Vertex Buffer Object ทำงานได้ดังนี้ (รหัสหลอก): โดยปกติถ้าใครอยากพูดให้วาดสี่เหลี่ยมจัตุรัสหนึ่งสามารถออกคำสั่งการวาดเส้น line (0, 0) -> (1, 0) line (1, 0) -> (1, 1) line (1, 1) -> (0, 1) line (0, 1) -> (0, 0) การใช้ VBO ถ้าฉันเข้าใจถูกต้องจะโหลดจุดยอดลงใน VBO define VBO load (0,0) -> VBO load (1,0) -> VBO load (1,1) -> VBO load …

2
วิธีที่มีประสิทธิภาพที่สุดในการจัดระเบียบข้อมูลจุดสุดยอดของ GPU สมัยใหม่
บอกว่าผมมีรูปแบบที่สร้างขึ้นจากจุดแต่ละคนมีposition, normal, tangentและtexcoordแอตทริบิวต์ที่สามเหลี่ยมถูกกำหนดโดยดัชนีอเนกประสงค์ หากเราเพียง แต่มุ่งเน้นไปที่คุณลักษณะจุดสุดยอดฉันรู้ว่ากลยุทธ์สองอย่างกว้าง ๆ : โครงสร้างของอาร์เรย์และอาร์เรย์ของโครงสร้าง ฉันเคยได้ยินเช่นกันว่าอาเรย์ของโครงสร้างเป็นที่ต้องการเพราะมันจะเพิ่มตำแหน่งหน่วยความจำ (และเพื่อให้ตำแหน่งแคช) ของคุณลักษณะสำหรับจุดสุดยอดที่กำหนด เป็นกรณีที่ปรับปรุงประสิทธิภาพได้จริงหรือไม่ วิธีหลักที่ฉันคิดว่าสิ่งนี้จะเกิดขึ้นได้โดยดัชนีจุดสุดยอดที่ต้องการให้ rasterizer ได้รับข้อมูลจุดสุดยอดที่มีความยาวตั้งแต่ถูกไล่ออกจากแคช หากการเข้าถึงข้อมูลจุดสุดยอดเป็นแบบสุ่มการเก็บแอตทริบิวต์ทั้งหมดสำหรับจุดสุดยอดในบรรทัดแคชเดียวกันจะทำให้สิ่งต่าง ๆ เร็วขึ้น แต่นี่ไม่ใช่ปัญหาที่สามารถลดลงได้ส่วนใหญ่โดยการปรับลำดับของข้อมูลจำเพาะสามเหลี่ยมให้เหมาะสมหรือไม่ นอกจากนี้ฉันเข้าใจว่า GPU สมัยใหม่อาจดีกว่าในการแกะเวกเตอร์ที่มีความยาวชนิดเดียวกันออกได้ดีกว่าเวกเตอร์ของโครงสร้างหลายประเภท มันจะเป็นไปได้หรือไม่สำหรับโครงร่างแบบโครงสร้างของอาร์เรย์เพื่อให้มีประสิทธิภาพเหนือกว่าโครงร่างอาร์เรย์ของโครงสร้างของข้อมูลจุดสุดยอดเดียวกันหากคำสั่งดัชนีถูกปรับให้เหมาะสม

1
ประสิทธิภาพของการแลกเปลี่ยนระหว่างการเรนเดอร์ไปข้างหน้าและการเรนเดอร์เป็นอย่างไร
การเรนเดอร์ไปข้างหน้าเป็นกระบวนการคำนวณค่าความกระจ่างสำหรับชิ้นส่วนพื้นผิวโดยตรงจากเรขาคณิตอินพุตและข้อมูลแสง การเรนเดอร์แบบแยกเป็นการประมวลผลที่แบ่งออกเป็นสองขั้นตอน: ขั้นแรกให้สร้างบัฟเฟอร์พื้นที่หน้าจอที่มีคุณสมบัติของวัสดุ (บัฟเฟอร์เรขาคณิตหรือ G-buffer) ที่สร้างขึ้นโดย rasterizing เรขาคณิตอินพุตและอันดับที่สองสร้างค่าเรเดียนสำหรับแต่ละพิกเซล บัฟเฟอร์ด้วยข้อมูลแสง การเรนเดอร์ที่ถูกเลื่อนมักจะถูกนำเสนอเป็นการปรับการเรนเดอร์ล่วงหน้า คำอธิบายอย่างหนึ่งคือแสงมีราคาค่อนข้างแพงและหากคุณมีการหักเงินมากเกินไปคุณก็จะเป็นพิกเซลแสงที่จะไม่ปรากฏบนหน้าจอในขณะที่ถ้าคุณเก็บคุณสมบัติของวัสดุไว้ใน G-buffer และแสงหลังจากนั้น จริง ๆ แล้วปรากฏบนหน้าจอ นี่เป็นข้อได้เปรียบของการเลื่อนเวลาออกไปหรือไม่เนื่องจากคุณสามารถทำ pre-pass ในระดับลึกได้และจากนั้นจะทำการส่งเรนเดอร์พาสด้วยการทดสอบความลึกที่ตั้งไว้D3D11_COMPARISON_EQUALหรือGL_EQUALหรือเทียบเท่า การเรนเดอร์ยังมีศักยภาพในการกำหนดตารางเวลาที่ดีขึ้นสำหรับ GPU การแยกวาร์ป / คลื่นขนาดใหญ่หนึ่งอันออกเป็นคลื่นเรขาคณิตที่เล็กกว่าจากนั้นแสงคลื่นที่เล็กลงจะช่วยเพิ่มอัตราการเข้าพักได้ในภายหลัง แต่คุณก็จบลงด้วยการใช้แบนด์วิดท์ที่มากขึ้น (เขียนช่องจำนวนมากไปยัง G-buffer แล้วอ่านกลับในช่วงแสง) แน่นอนว่าข้อมูลเฉพาะที่นี่ขึ้นอยู่กับ GPU ของคุณมาก แต่หลักการทั่วไปคืออะไร? มีข้อควรพิจารณาเกี่ยวกับประสิทธิภาพอื่น ๆ เมื่อตัดสินใจระหว่างการเรนเดอร์ไปข้างหน้าและการเรนเดอร์ที่เลื่อนออกไปหรือไม่? (สมมติว่าเราสามารถใช้ความหลากหลายของแต่ละเทคนิคได้หากจำเป็น: เช่นเราสามารถเปรียบเทียบกระเบื้องไปข้างหน้ากับกระเบื้องที่เลื่อนออกไปเช่นกัน)
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.