Screen Test Pro คำนวณคะแนน benchmark อย่างไร

นี่คือหน้าอธิบายวิธีการวัด ไม่มีอะไรในหน้านี้ถูกลดทอนเพื่อการตลาด หากโค้ดกับหน้านี้ขัดแย้งกันเมื่อใด นั่นคือข้อบกพร่องและเราอยากทราบ (เวอร์ชัน benchmark ณ เวลาที่เขียน: 2.2.0)

คำถามที่ benchmark ถาม

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

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

สิ่งที่ถูกรัน

โปรไฟล์มาตรฐานประกอบด้วยฉาก Signature ห้าฉากบวกฉากควบคุมหนึ่งฉาก โดยแต่ละฉากรีดคนละแกน

การเรนเดอร์ใช้อัตราส่วนพิกเซลที่จำกัดไว้ที่ 1.5× พร้อมเพดานขนาดภายใน จอ 5K กับโน้ตบุ๊ก 1080p จึงเจอจำนวนพิกเซลที่เทียบกันได้ ค่าสุ่มใช้ค่าเริ่มต้นที่กำหนดไว้และขั้นการจำลองถูกตรึงไว้ ทุกการรันของเวอร์ชันเดียวกันจึงทำงานเหมือนกันทุกประการ

ตัดสินความเสถียรอย่างไร

เอนจินไม่เคยอ่านตัวนับ FPS เลย แต่จะเก็บเวลาต่อเฟรมจากนาฬิกาแอนิเมชันของเบราว์เซอร์ลงในหน้าต่างขนาดราว 0.7–1.6 วินาที แล้วตั้งเงื่อนไขสองข้อกับทุกหน้าต่าง

• มีเฟรมที่พลาดเกณฑ์การผ่านได้ไม่เกิน 5% โดยเกณฑ์คือ 17.5 ms บนจอที่ซิงก์แบบปรับได้ ส่วนบนจอความถี่คงที่คือช่องเวลา vsync ช่องแรกที่งานซึ่งอยู่ในงบเวลาไม่มีทางไปลงได้ (25.0 ms ที่ 60 Hz และ 20.8 ms ที่ 120 Hz)
• ค่าเฉลี่ยแบบตัดปลาย ซึ่งตัดเฟรมที่แย่ที่สุด 2% ออก ต้องอยู่ภายใน 16.67 ms × 1.15

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

เหตุผลที่เกณฑ์ต้องสนใจจอของคุณ คือจอความถี่คงที่ 60 Hz แสดงเฟรมได้ที่ 16.7 ms หรือ 33.3 ms และไม่มีค่ากลางระหว่างนั้น ขณะที่จอโน้ตบุ๊กแบบซิงก์ปรับได้จะคืนเฟรมขนาด 18 ms ออกมาเป็น 18 ms ตรง ๆ ภายใต้ค่าความคลาดเคลื่อนแบบค่าเฉลี่ยและ P95 ของเวอร์ชัน 2.1.0 ความต่างนี้ทำให้จอปรับได้แล่นอยู่ที่ 55 fps แล้วผ่านเกณฑ์ ในขณะที่จอ 60 Hz ต้องรักษา 60 จริง ๆ GPU ตัวเดียวกันจึงได้คะแนนต่ำกว่าเมื่ออยู่บนโต๊ะเทียบกับตอนอยู่ในจอโน้ตบุ๊ก ดังนั้นก่อนเริ่มฉากแรก การตรวจจังหวะจอราว 600 ms จะเฝ้าดูว่าจอของคุณคืนเฟรมอย่างไร แล้วปรับเกณฑ์ให้คำว่า “รักษา 60 fps ได้” มีความหมายเดียวกันในจอทุกประเภท และหากการตรวจพบว่าจอถูกจำกัดไว้ต่ำกว่าราว 50 Hz เช่นจากโหมดประหยัดพลังงานหรือสายที่ส่งได้แค่ 30 Hz การทดสอบจะปฏิเสธการเริ่ม แทนที่จะตัดสิน GPU ผ่านช่องแคบ ๆ ขนาด 30 Hz

ส่วนงบเวลา 16.67 ms นั้นไม่เคยเปลี่ยนตามอัตรารีเฟรช จอ 120 Hz ส่งเฟรมด้วยจังหวะ 8.3 ms เมื่องานเบา แต่การจะผ่านเกณฑ์ต้องการเพียงให้อยู่ในงบ 60 เฟรมต่อวินาทีเท่านั้น ฮาร์ดแวร์ที่รีเฟรชสูงจึงถูกวัดบนพื้นฐานที่เท่าเทียม ไม่ถูกลงโทษเพราะแสดงเฟรมส่วนเกินออกมา

การค้นหา

แต่ละฉากเดินผ่านเครื่องสถานะ: preflight → baseline → warmup → ramp → bracket → confirm → anchor

1. Baseline วัดภาระเบาที่รู้ค่าอยู่แล้ว ค่านี้จะกลายเป็นค่าอ้างอิงด้านความร้อน
2. Ramp คูณภาระงานราว 1.5× ต่อหนึ่งหน้าต่างที่ผ่าน จนกระทั่งมีหน้าต่างหนึ่งไม่ผ่าน
3. Bracket ค้นหาแบบแบ่งครึ่งระหว่างค่าที่ผ่านล่าสุดกับค่าที่ไม่ผ่านค่าแรก จนช่วงแคบลงเหลือราว 6%
4. Confirm เรียกร้องหน้าต่างที่ผ่านติดต่อกันสามรอบที่ระดับภาระซึ่งกำลังพิจารณา ภายในงบสี่รอบ หน้าต่างที่แย่หนึ่งรอบในช่วงต้นยังกู้คืนได้ แต่ถ้าไม่ผ่านติดกันสองครั้ง หรือใช้งบจนหมดโดยไม่ได้สามรอบติด ระดับนั้นจะถูกปฏิเสธและค่าที่พิจารณาจะลดลงหนึ่งขั้น
5. Anchor รันภาระอ้างอิงซ้ำอีกครั้ง หากตอนนี้ช้าลงเกิน 15% เทียบกับตอนเริ่ม แปลว่าอุปกรณ์เปลี่ยนไประหว่างการวัด ซึ่งแทบทุกครั้งคือการลดความเร็วจากความร้อน ฉากนั้นจะถูกติดป้าย คลาดเคลื่อน แทนที่จะแกล้งทำเป็นว่าไม่มีอะไรเกิดขึ้น และระบบยังบันทึกขนาดของการช้าลงไว้ด้วย ไม่ใช่แค่ว่ามันเกิดขึ้น

เฟรมไม่กี่เฟรมหลังการเปลี่ยนระดับภาระทุกครั้งจะถูกตัดทิ้งก่อนเริ่มเก็บสถิติต่อ เพราะการเปลี่ยนระดับภาระต้องจองบัฟเฟอร์และเป้าหมายการเรนเดอร์ของ GPU ใหม่ ซึ่งเบราว์เซอร์คิดต้นทุนนั้นเป็นเฟรมยาวหนึ่งเฟรม อาการสะดุดนั้นเป็นของช่วงเปลี่ยนผ่าน ไม่ใช่ของภาระงาน เวอร์ชัน 2.1.0 นับมันเข้าไปด้วย และในฉากที่ต้องปรับขนาดเป้าหมายการเรนเดอร์ทุกขั้นบันได มันทำให้การค้นหาหยุดต่ำกว่าที่ฮาร์ดแวร์รับไหวจริงอยู่มาก

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

จากภาระงานสู่คะแนน

การให้คะแนนเป็นฟังก์ชันบริสุทธิ์ที่คำนวณจากผลที่บันทึกไว้ คุณคำนวณตามด้วยมือได้

1. ภาระสูงสุดที่ยังเสถียรของแต่ละฉากจะถูกหารด้วยภาระอ้างอิงของฉากนั้น ซึ่งเป็นค่าคงที่จากการปรับเทียบที่ตรึงไว้ในแต่ละเวอร์ชัน โดยคร่าว ๆ เครื่องตั้งโต๊ะที่ดีของปี 2025 จะได้ค่าใกล้ 1.0
2. อัตราส่วนมีพื้นที่ 0.05 และมีเพดานอยู่ที่เพดานบันไดของฉากนั้นเอง คือภาระที่หนักที่สุดเท่าที่ฉากนั้นจัดแสดงได้จริงทางกายภาพ ซึ่งตั้งไว้สูงกว่าฮาร์ดแวร์ที่เร็วที่สุดที่เราวัดมาราว 10 เท่า คะแนนจึงหยุดไต่ขึ้นได้เฉพาะจุดที่การวัดเองสิ้นสุดลงเท่านั้น (เวอร์ชัน 2.1.0 ตัดทุกฉากไว้ที่ 20× เท่ากันหมด เครื่อง M4 Max จึงชนเพดานนี้ไปสองฉากและชนเพดานการวัดอีกหนึ่งฉาก นี่คือเหตุผลที่เครื่องเรือธงของ Apple ซึ่งไม่เกี่ยวข้องกันเลยกลับรายงานคะแนนรวมใกล้เคียงกันมาก)
3. อัตราส่วนที่ถูกตัดแล้วจะถูกรวมด้วยค่าเฉลี่ยเรขาคณิตแบบถ่วงน้ำหนัก โดยฉาก Signature ทั้งห้ารับน้ำหนักส่วนใหญ่ และฉากควบคุม Canvas 2D รับ 10% ที่ใช้ค่าเฉลี่ยเรขาคณิตก็เพราะมันให้รางวัลกับความสมดุล เครื่องที่ทำได้ดีทุกด้านจะชนะเครื่องที่เก่งสุดยอดด้านเดียวแต่แย่มากในอีกด้าน
4. คูณด้วย 1000 แล้วหักคะแนนความเสถียร คือ 3% ต่อหนึ่งฉากที่ถูกติดป้าย ไม่ว่าจะเป็นความคลาดเคลื่อนหรือระดับที่ยืนยันไม่ได้ โดยหักรวมได้ไม่เกิน 10% จากนั้นจึงปัดเศษ

ระดับชั้นเป็นเกณฑ์คงที่ของแต่ละเวอร์ชัน และเพราะคะแนนคือ 1000 เท่าของเครื่องอ้างอิง แต่ละระดับจึงเป็นจำนวนเท่าของเครื่องนั้นจริง ๆ ได้แก่ เริ่มต้น ต่ำกว่า 1000 สมดุล ถึง 2999 เร็ว ถึง 8999 และ สูงสุด เหนือกว่านั้น หรือพูดอีกอย่างคือต่ำกว่า 1× ไม่เกิน 3× ไม่เกิน 9× แล้วจึงเกินกว่านั้น ระดับชั้นมีไว้ให้ตัวเลขมีที่จับ แต่คะแนนรายฉากคือข้อมูลจริง

อะไรทำให้เปรียบเทียบกันไม่ได้

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

ความแปรปรวนระหว่างการรัน และสิ่งที่ควรคาดหวัง

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