สร้าง benchmark บนเบราว์เซอร์ที่ค้างไม่ได้

benchmark มักล้มเหลวในแบบที่น่าอาย บ้างค้างอยู่ที่ 97% บ้างรายงานตัวเลขที่แกว่งถึง 30% ระหว่างการรันแต่ละครั้ง บ้างให้คะแนนโน้ตบุ๊กของคุณต่ำลงเพียงเพราะมันมีจอที่ดีกว่า ตอนสร้างของเราขึ้นใหม่สำหรับเวอร์ชัน 2.0 เราติดรายการความล้มเหลวเหล่านี้ไว้เหนือโต๊ะทำงาน และออกแบบเพื่อรับมือกับแต่ละข้ออย่างเจาะจง นี่คือบันทึกบางส่วนจากกระบวนการนั้น

กลับด้านการวัด

รูปแบบดั้งเดิมคือกำหนดภาระงานคงที่แล้ววัด FPS ซึ่งบนเบราว์เซอร์แทบไม่มีประโยชน์เลย เครื่องที่เร็วจะติดเพดานอยู่ที่อัตรารีเฟรชของจอ เพราะเบราว์เซอร์ไม่เรนเดอร์เร็วกว่าการซิงก์ภาพ ทุกเครื่องที่ดีจึงรายงานออกมาเป็น “60” หรือ “120” เหมือนกันหมด ส่วนเครื่องที่ช้าจะให้ภาพกระตุกเป็นสไลด์ ซึ่งวัดความอดทนของคุณมากกว่าประสิทธิภาพของเครื่อง

เราจึงตรึงเป้าหมายไว้แทน คือกำหนดงบเวลาต่อเฟรมที่ 16.67 ms แล้วให้ภาระงานเป็นตัวแปร แต่ละฉากจะเพิ่มจำนวนอนุภาคขึ้นเรื่อย ๆ จนเฟรมเกินงบเวลา แล้วค้นหาเส้นแบ่งด้วยวิธีแบ่งครึ่ง จากนั้นจึงเรียกร้องหน้าต่างยืนยันที่สะอาดติดต่อกันสามรอบก่อนจะรับระดับนั้น ผลลัพธ์ที่ได้คือ “ภาระสูงสุดที่ยังเสถียร” ซึ่งมีความหมายเชิงกายภาพที่นึกภาพตามได้ เช่น เครื่องนี้ดันอนุภาคเนบิวลาได้ 840,000 จุดก่อนจะเริ่มตกเฟรม

benchmark ที่กลับด้านแบบนี้ยังล้มเหลวอย่างนุ่มนวลโดยโครงสร้าง อุปกรณ์ที่อ่อนกว่าไม่ได้ให้ผลทดสอบที่พัง แต่เพียงไปหยุดอยู่ที่ขั้นบันไดที่ต่ำกว่าบนบันไดเดียวกัน

ใช้เปอร์เซ็นไทล์ เพราะการกระตุกโกหกเก่ง

ทุกหน้าต่างการวัดถูกตัดสินทั้งจากเวลาต่อเฟรมเฉลี่ยและเปอร์เซ็นไทล์ที่ 95 เกณฑ์ p95 มีอยู่เพราะค่าเฉลี่ยฟอกอาการกระตุกให้ดูสะอาด เครื่องที่เรนเดอร์ทันเวลา 95 เฟรมและช้าถึง 40 ms อีก 5 เฟรมนั้นใช้แล้วรู้สึกแย่ แต่ค่าเฉลี่ยกลับดูดี การตั้งเกณฑ์ที่เปอร์เซ็นไทล์คือวิธีเปลี่ยนคำว่า “รู้สึกแย่” ให้กลายเป็นตัวเลข หน้าต่างที่ผิดปกติเพียงรอบเดียว เช่น มีการแจ้งเตือนเด้งขึ้นมาหรือตัวเก็บขยะหน่วยความจำหยุดทำงานชั่วครู่ จะถูกวัดใหม่แทนที่จะนับ แต่ถ้าล้มเหลวติดกันสองครั้งจะถือว่าไม่ผ่านระดับนั้น ระบบให้อภัยอุบัติเหตุ แต่ไม่ปล่อยผ่านรูปแบบที่เกิดซ้ำ

เครื่องสถานะขี้ระแวง

ข้อกำหนดที่ว่า “ค้างไม่ได้” ทำให้เกิดโค้ดที่ดูไม่หวือหวาที่สุดแต่แบกรับงานมากที่สุดในโครงการนี้ ทุกฉากทำงานด้วยเครื่องสถานะ ประกอบด้วยการตรวจก่อนบิน การวัดค่าอ้างอิง การอุ่นเครื่อง การไต่ระดับ การไล่กรอบ การยืนยัน และการตรึงค่า โดยทุกสถานะมีทางออกที่ตายตัว

ในช่วงที่พัฒนาเวอร์ชัน 2.0 หนึ่งฉากได้เวลา 30 วินาที และการทดสอบทั้งชุดได้ 150 วินาที เท่านั้น
การสลับแท็บไปไว้เบื้องหลังจะทำให้หน้าต่างการวัดปัจจุบันเป็นโมฆะและหยุดชั่วคราว ถ้าซ่อนนานเกิน 30 วินาที การทดสอบจะจบลงพร้อมระบุเหตุผล
การปรับขนาดหน้าต่างหรือการเปลี่ยนอัตราส่วนพิกเซลจะสร้างฉากใหม่และอุ่นเครื่องใหม่ แทนที่จะวัดค่าขยะ
การสูญเสียบริบท WebGL, GPU ที่ค้าง (ไม่มีเฟรมออกมาหลายวินาที) หรือฉากที่เกิดข้อผิดพลาด แต่ละกรณีจะจับคู่กับเหตุผลการออกของตัวเอง และตัวเฝ้าระวังยังเดินต่อแม้ลูปเรนเดอร์จะเดินไม่ได้แล้ว
ปุ่ม Escape ใช้ได้ในทุกสถานะที่ว่ามา เพราะปุ่มยกเลิกที่ทำงานเฉพาะตอนทุกอย่างปกติดีนั้นไม่นับเป็นปุ่มยกเลิก

การทดสอบจบก่อนกำหนดได้ จบแบบประสิทธิภาพลดลงได้ หรือถูกยกเลิกได้ สิ่งเดียวที่มันทำไม่ได้คือค้างนิ่งอยู่เฉย ๆ

ความซื่อสัตย์เรื่องความร้อน

ภาระ GPU ที่ต่อเนื่องทำให้เครื่องร้อน เครื่องที่ร้อนจะช้าลง และ benchmark ที่มองข้ามเรื่องนี้ก็เท่ากับแอบเฉลี่ยนาทีที่ดีที่สุดของอุปกรณ์เข้ากับนาทีที่แย่ที่สุดอย่างเงียบ ๆ ทุกฉากจึงวัดภาระอ้างอิงแบบเบาสองครั้ง คือครั้งหนึ่งตอนเริ่มและอีกครั้งตอนจบ หากค่าที่อ่านครั้งที่สองช้าลงเกิน 15% ฉากนั้นจะถูกติดป้าย ประสิทธิภาพลดลง และป้ายนี้จะติดไปถึงการ์ดผลลัพธ์และคะแนน โดยหักคะแนนแบบมีเพดาน รวมถึงติดไปถึงชุดข้อมูลด้วยหากคุณเลือกส่งตัวอย่าง ค่ามัธยฐานสาธารณะจึงคัดผลที่เครื่องร้อนออกได้แทนที่จะกลืนมันเข้าไป

ความยุติธรรมต่อจอรีเฟรชสูง

มีกับดักที่ละเอียดอ่อนอยู่ข้อหนึ่ง หากตัดสินอย่างซื่อ ๆ ตามรอบรีเฟรชของตัวเอง โน้ตบุ๊กจอ 120 Hz จะต้องเรนเดอร์ทุกเฟรมให้เสร็จใน 8.3 ms จึงจะเรียกว่า “ตามรีเฟรชทัน” ซึ่งหนักเป็นสองเท่าของเครื่องที่ใช้จอ 60 Hz งบเวลาของเราจึงตรึงไว้ที่ 16.67 ms เท่ากันสำหรับทุกเครื่อง จอรีเฟรชสูงยังรู้สึกถึงข้อได้เปรียบของตัวเองอยู่ เพราะมันแสดงเฟรมส่วนเกินได้เมื่อภาระเบา แต่เส้นแบ่งผ่านหรือไม่ผ่านอยู่ที่เดียวกันบนจอทุกแบบ จอภาพเป็นทางเลือกของการรับชม ส่วนหน้าที่ของ benchmark คือวัดคอมพิวเตอร์ที่อยู่ข้างหลังจอนั้น

สิ่งที่เราตั้งใจไม่ใส่เข้าไป

ยังไม่มี WebGPU หากจะมีก็จะมาในรูปแบบโปรไฟล์แยกที่มีสเกลคะแนนของตัวเอง ไม่ใช่การสลับเข้ามาเงียบ ๆ ใต้ตัวเลขเดิม เวอร์ชันนี้ยังไม่ใช้ web worker ในการเรนเดอร์ เพราะพื้นที่ความล้มเหลวที่เพิ่มเข้ามา ทั้ง worker ตาย การส่งบริบทข้ามเธรด และอินพุตข้ามเธรด ล้วนขัดกับข้อกำหนดที่ว่าห้ามค้าง อีกทั้งภาระงานที่วัดได้ก็เท่ากันทั้งสองทาง และเราจะยังไม่กล่าวอ้างค่าเปอร์เซ็นไทล์บนการ์ดผลลัพธ์จนกว่าชุดข้อมูลแบบไม่ระบุตัวตนจะผ่านเกณฑ์จำนวนตัวอย่างที่แท้จริง เพราะเปอร์เซ็นไทล์ที่คำนวณจากผลสี่สิบครั้งเป็นเพียงความรู้สึกที่สวมเสื้อคลุมของตัวเลข

ข้อกำหนดฉบับเต็มพร้อมสูตรคำนวณคะแนนเขียนไว้ในหน้าวิธีการวัด หากคุณพบอุปกรณ์ที่ทำให้ข้อใดข้อหนึ่งข้างต้นไม่เป็นจริง นั่นคือข้อบกพร่อง แจ้งได้ที่ admin แอท screentest.pro