מה זה Hardware-Accelerated GPU Scheduling ב-Windows — האם On מאיץ את המחשב?

כשפותחים את הגדרות Windows אפשר למצוא מתג עם שם ארוך: “Hardware-accelerated GPU scheduling”.

טבעי לחשוב שאם זה “hardware-accelerated”, On יהיה מהיר יותר. אבל זה לא כפתור שמעלה את ביצועי ה-GPU במדרגה.

זה לא מחליט אם משתמשים ב-GPU; זה משנה איך מנהלים את העבודה של ה-GPU. השם המלא הוא Hardware-accelerated GPU scheduling, ובקיצור HAGS.¹

המאמר הזה הוא מבוא למשתמשים כלליים שסקרנים לגבי ההגדרה ב-Windows 11. אין צורך בידע בתכנות. הוא מסביר את המנגנון ואיך מחליטים, על בסיס חומר רשמי שנבדק ב-5 בספטמבר 2026. זה אינו מאמר benchmark שמדד הפרשי ביצועים במחשב מסוים.

1. גם ל-GPU יש “פיקוח תנועה”

ה-GPU הוא המעבד שאחראי על משימות כמו ציור המסך. הוא לא שייך למשחק אחד; הוא מקבל עבודה מכמה אפליקציות, כולל הדפדפן ושולחן העבודה עצמו.

כשאפליקציה אחת ממשיכה לשלוח עבודה, משהו צריך לתאם כדי שהאחרות יישארו מגיבות. הרכיב שמנהל את סדר הביצוע ואת הקצאת הזמן הוא GPU scheduler. Windows מספק את מנגנון הניהול הזה.²

flowchart TB
    accTitle: כמה אפליקציות משתמשות ב-GPU
    accDescr: ה-scheduler מתאם עבודה ממשחקים, דפדפנים ואפליקציות אחרות ומעביר אותה ל-GPU.
    A["משחק"] --> S["תיאום עבודת GPU"]
    B["דפדפן"] --> S
    C["תצוגת שולחן העבודה"] --> S
    S --> G["הרצה ב-GPU"]

איור 1: שימוש ב-GPU דורש, בנוסף לחישוב עצמו, מנגנון שמתאם את העבודה.

למשל, ה-GPU הוא העובד שמבצע את המשימה, וה-scheduler הוא מי שמסדר את התור. היכולת של העובד ואופן מסירת העבודות הם שני דברים שונים.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 11, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מה ש-HAGS משנה הוא מי מטפל בעבודת הניהול

בעבר, קוד שרץ על ה-CPU תיאם את עבודת ה-GPU. עם HAGS, חלק גדול מעבודת הניהול שמתרחשת לעתים קרובות — הקצאת זמן ביצוע והחלפה בין משימות — עובר למנגנון ייעודי בצד ה-GPU. מדיניות איזו אפליקציה מקבלת עדיפות נשארת בידי Windows. לא כל עבודת ה-CPU עוברת ל-GPU.¹

flowchart TB
    accTitle: מה HAGS משנה במי שמטפל בניהול
    accDescr: Windows מנהל עדיפויות בשני המקרים; מה שמשתנה הוא מי מטפל בניהול הביצוע בתדירות גבוהה.
    W["Windows מנהל את העדיפויות"] --> O["Off: ניהול ביצוע בצד ה-CPU"]
    W --> N["On: חלק גדול מהניהול עובר לצד ה-GPU"]
    O --> G["ה-GPU מריץ את העבודה"]
    N --> G

איור 2: בין אם HAGS דולק ובין אם כבוי, ה-GPU מריץ את העבודה.

מכאן אפשר גם לנקות כמה אי-הבנות נפוצות.

כיבוי HAGS לא עוצר rendering רגיל של GPU. הוא גם לא מוסיף יחידות חישוב ל-GPU ולא מגדיל את נפח ה-video memory. בשם המתג יש “accelerated”, אבל המילה שחשוב להתמקד בה היא החצי השני: “scheduling”.

שימו לב שאף על פי שניהול זיכרון GPU ו-scheduling קשורים, התיעוד של Windows מפריד בין התפקידים. לחשוב על HAGS כ”הגדרה שמגדילה video memory” הוא גם טעות.³

3. אז, האם On מאיץ?

שיפור במנגנון אינו אותו דבר כמו שאפליקציה שלכם נראית מהירה יותר.

בהסבר בזמן ההשקה, Microsoft ציינה שעומס עבודת הניהול כבר הפך פחות מורגש בזכות מנגנון של שליחת עבודת GPU באצוות. היא לא טענה שהמעבר ל-HAGS תמיד מביא שינוי ביצועים גדול. זה הסבר תכנון מ-2020, לא מסקנה מהשוואת ביצועים של כל GPU וכל אפליקציה כיום.¹

flowchart TB
    accTitle: מסירת עבודה ויכולת ציור הן דברים נפרדים
    accDescr: מפרידים בין ניהול העבודה ש-HAGS משפיע עליו לבין הכנה ב-CPU וציור ב-GPU.
    A["ה-CPU מעבד ומכין את ה-frame"] --> B["ניהול העבודה שנשלחת ל-GPU"]
    B --> C["ה-GPU מצייר"]
    H["החלק ש-HAGS משנה"] -.-> B

איור 3: שיפור בחלק אחד של ה-pipeline משפיע מעט אם חלק אחר קובע את זמן העיבוד.

למשל, אם ה-GPU מבלה את הזמן בחישוב שצריך כדי לצייר frame אחד, שינוי רק באופן מסירת העבודה לא מקטין את כמות החישוב. במקום לצפות ש”משחק כבד ייעשה קל בהגדרה אחת”, עדיף לחשוב על HAGS כהגדרה לבדיקה אם יש הבדל בסביבה שלכם.

גם במחשב שלא משחקים בו, HAGS קשור לכל עיבוד שמשתמש ב-GPU. אבל לא “אני משתמש רק בדפדפן, אז זה לא רלוונטי” ולא “סרטונים בטוח ינועו חלק יותר” אפשר לשפוט לפי שם השימוש בלבד.

4. On או Off לפי “צורך” ו”יציבות”

המאמר ממליץ להחליט בסדר הבא.

flowchart TB
    accTitle: החלטה אם לשנות HAGS
    accDescr: קודם בודקים את דרישות ה-features שצריכים; אם אין כאלה, מחליטים לפי היציבות הנוכחית ומטרת ההשוואה.
    A{"Feature שצריכים דורש HAGS?"} -->|"כן"| B["מדליקים לפי הדרישות הרשמיות"]
    A -->|"לא"| C{"יש אי-שביעות רצון מהמצב הנוכחי?"}
    C -->|"לא"| D["מתחילים מהמצב היציב הקיים"]
    C -->|"כן"| E["משנים רק HAGS ומשווים"]

איור 4: מתחילים מהשימוש שלכם, לא מ”On כי זה חדש” או “Off כי קראתי מאמר על תקלה”.

אם feature שרוצים להשתמש בו דורש HAGS, הדרישה קודמת. למשל, לפי ההנחיה הרשמית של Nixxes, שימוש ב-DLSS Frame Generation של NVIDIA דורש ש-HAGS יהיה מופעל. HAGS עצמו לא מייצר frames ביניים; נדרשים בנפרד גם GPU נתמך, משחק נתמך, וההגדרה בתוך המשחק. זה חל על DLSS Frame Generation ולא ניתן להכליל כפי שהוא לכל frame generation של כל יצרן.⁴

לעומת זאת, אם אין feature שדורש את זה והמחשב יציב עכשיו, אין סיבה למהר לשנות. כשרוצים לחקור stutter או תופעות דומות, HAGS הופך למועמד להשוואה, אבל לא מניחים שהוא הסיבה; בודקים אם הבעיה חוזרת.

5. איך בודקים ומשנים ב-Windows 11

קודם שומרים קבצים שעובדים עליהם. אחר כך פותחים הגדרות > מערכת > תצוגה > גרפיקה ומחפשים את פריט HAGS. לפי גרסת Windows ייתכן שצריך לפתוח דף פירוט נוסף כמו “הגדרות גרפיקה המוגדרות כברירת מחדל”. שמות המסכים והפריסה משתנים לפי הסביבה.⁵

לפני השינוי, רושמים או מצלמים את מצב On/Off הנוכחי. אחרי השינוי לא מספיק לפתוח מחדש את האפליקציות; עושים restart ל-Windows ורק אז בודקים.⁴

flowchart TB
    accTitle: שלבים לשינוי HAGS ולבדיקה
    accDescr: רושמים את ההגדרה המקורית, משנים רק HAGS, ואז עושים restart ל-Windows ובודקים.
    A["רושמים את ההגדרה המקורית"] --> B["משנים רק HAGS"]
    B --> C["Restart ל-Windows ובדיקה"]

איור 5: אם רושמים את ההגדרה המקורית, לא הולכים לאיבוד כשמחזירים אחרי ההשוואה.

אין צורך להחליט לפי ערך ברירת מחדל שכתוב במאמר, כמו “תמיד On ב-Windows 11” או “תמיד Off”. מספיק לבדוק איך המחשב שלכם מוגדר עכשיו.

אם מופיעות תקלות, מחזירים להגדרה המקורית ועושים restart. במחשב בניהול החברה לא עוקפים הגבלות רק כי אי אפשר לשנות את ההגדרה; פונים למנהל.

6. כשההגדרה לא מופיעה

HAGS אינו זמין רק כי Windows תומך בו. גם ה-GPU עצמו וגם ה-graphics driver שמפעיל אותו צריכים לתמוך. בהשקה צוין כדרישה driver מסוג WDDM 2.7 שחושף את התמיכה ל-Windows. WDDM הוא מודל ה-display driver של Windows.¹

flowchart TB
    accTitle: סדר בדיקות כשההגדרה לא נמצאת
    accDescr: בודקים לפי הסדר את גרסת Windows, דגם ה-GPU ותמיכת ה-driver, ואז חוזרים למסך ההגדרות.
    A["בודקים את גרסת Windows"] --> B["בודקים את דגם ה-GPU"]
    B --> C["בודקים את מידע התמיכה של היצרן"]
    C --> D["בודקים driver נתמך ואת ההגדרה"]

איור 6: כשהפריט חסר, בודקים את מצב התמיכה לפני שצדים הגדרות נסתרות.

זהירות: מספר גרסת WDDM חדש יותר לבדו אינו מוכיח תמיכה ב-HAGS. ה-GPU וה-driver צריכים באמת לספק את היכולת.

למשל, החומר הרשמי של Intel שבדקתי מבחין בין סדרת Arc B, שנתמכת ב-Windows 11 22H2 ואילך, לבין סדרת Arc A שאינה נתמכת. אי אפשר להסתמך על כלל אצבע כמו “כל GPU יחסית חדש יכול להשתמש בזה”. בודקים את טווח התמיכה במידע הרשמי של הדגם המדויק.⁶

כשבודקים drivers, משתמשים באלה שיצרן המחשב או יצרן ה-GPU מספק לדגם הזה. זו לא יכולת ש-GPU לא נתמך מקבל על ידי הוספת ערך ב-Registry. המאמר הזה לא מכסה נהלים להפעלה כפויה של פריט שחסר במסך ההגדרות.

7. אם משווים, משנים דבר אחד בכל פעם

“מרגיש קל יותר מאתמול” לא מפריד בין האפקט של HAGS לבין שינוי בתנאים אחרים. מה שבא אינו תוצאות benchmark מחומר רשמי, אלא נוהל מעשי להשוואה.

קודם בוחרים פעולה אחת שחשובה ביום-יום. במשחק — אותו scene; בעריכת וידאו — אותו חומר ואותה פעולת ניגון. אם יש benchmark מובנה שקל לשחזר, אפשר להשתמש גם בו.

flowchart TB
    accTitle: משווים עד החזרה להגדרה המקורית
    accDescr: משווים את אותה פעולה בהגדרה המקורית ואחרי השינוי, ובודקים אם ההבדל חוזר כשמחזירים.
    A["חוזרים על אותה פעולה בהגדרה המקורית"] --> B["Restart אחרי שינוי HAGS"]
    B --> C["חוזרים על אותה פעולה"]
    C --> D["מחזירים, restart, ובודקים שוב"]

איור 7: השוואה לפני השינוי, אחריו, ואחרי ההחזרה מקלה לזהות הבדלים מקריים.

התנאים שמשאירים זהים כוללים רזולוציה, איכות גרפיקה, תקרת FPS, מצב צריכת חשמל, ואילו אפליקציות רצות. במחשב נייד גם מתאימים אם הוא מחובר לחשמל. אם מעדכנים driver באמצע ההשוואה, שני שינויים מתערבבים.

חוזרים על אותה פעולה כמה פעמים בכל הגדרה כדי שעבודת הכנה חד-פעמית בהרצה הראשונה לא תתערבב עם ההתנהגות הרגילה. במקום ערך שיא בודד, מסתכלים אם המגמה דומה בערך בכל פעם.

מסתכלים גם על “stutter”, לא רק על FPS ממוצע

FPS הוא מספר ה-frames לשנייה. Frame time, לעומת זאת, הוא מדד של הזמן לכל frame במילישניות. צריך גם לשים לב לאיזה מרווח כלי המדידה מודד, אבל ב-60 FPS יציב, למשל, כל frame לוקח בערך 16.7 מילישניות. גם כשהממוצעים קרובים, האם יש המתנות ארוכות באמצע היא שאלה נפרדת.

flowchart TB
    accTitle: בודקים מהירות ויציבות בנפרד
    accDescr: בהשוואה בודקים בנפרד מהירות ממוצעת, stutter, ויציבות האפליקציה.
    A["תוצאות אותה פעולה"] --> B["מהירות ממוצעת"]
    A --> C["stutter בדרך"]
    A --> D["יציבות תצוגה והתנהגות"]

איור 8: גם אם ה-FPS הממוצע קצת יותר גבוה, יותר stutter או תקלות תצוגה לא מסתכמים לחוויה נוחה יותר.

אם יש יכולת מדידה, בודקים גם את השונות ב-frame time. בלי כלי כזה, עדיין אפשר לרשום באיזו פעולה היה stutter, אם התצוגה השתבשה, ואם האפליקציה נסגרה. אבל מבט בעין או FPS ממוצע לבדם אינם מדידה מדויקת של ה-latency מהקלט בעכבר עד התצוגה על המסך.

בהשוואה של HAGS לבדו, משאירים זהים גם תנאים כמו frame generation. אם כיבוי HAGS גם הפך את DLSS Frame Generation ללא זמין, הפרש ה-FPS אינו הפרש של scheduling בלבד. להשוואה שמחפשת את ההפרש הבודד, מכבים frame generation בשני התנאים, ומפרידים את זה מהשוואת נוחות כללית עם ה-features שמשתמשים בהם בדרך כלל.⁴

אם ההפרש קטן והמנצח מתחלף כשחוזרים על הבדיקה, “לא אושר הפעם הבדל ברור” היא המסקנה המתאימה.

8. לא לבלבל עם הגדרות בעלות שם דומה

“Graphics acceleration” בתוך דפדפן היא הגדרה על השימוש של האפליקציה הזו ב-GPU. היא שונה מ-GPU scheduling כלל-מערכתי ב-Windows גם במקום שבו משנים אותה וגם במה שהיא עושה. ל-Edge, למשל, יש הגדרה בצד הדפדפן שמפעילה או מכבה את ה-graphics acceleration הזמינה לו.⁷

flowchart TB
    accTitle: ההבדל בין שימוש של אפליקציה ב-GPU לבין HAGS
    accDescr: הגדרת האצה בצד האפליקציה נוגעת לשימוש ב-GPU; HAGS נוגע לאופן ניהול העבודה.
    A["הגדרה בצד הדפדפן"] --> B["עיבוד שמשתמש ב-GPU"]
    C["HAGS בצד Windows"] --> D["איך מנהלים את עבודת ה-GPU"]

איור 9: למרות השמות הדומים, שימוש של אפליקציה ב-GPU וניהול העבודה הזו הם דברים נפרדים.

הגדרות שקשורות ל-CPU ולחיסכון בחשמל, כמו Efficiency mode ב-Task Manager, מכוסות במאמר נפרד, עדיפות CPU, affinity וחיסכון בחשמל. אם מחליפים אותן יחד עם HAGS, לא יידעו איזה שינוי השפיע, ולכן בהשוואה משנים דבר אחד בכל פעם.

סיכום

HAGS אינו הגדרה שהופכת את ה-GPU למוצר מהיר יותר; זו הגדרה שמשנה איך מוסרים עבודה ל-GPU.

בודקים את דרישות ה-features שצריכים, ומתחילים מהמצב היציב הקיים. אם מנסים, רושמים את ההגדרה המקורית, משנים רק HAGS, עושים restart, ומשווים באותה פעולה. בסדר הזה מקבלים תשובה שעוזרת למחשב שלכם, ולא הכללה אם “On” הוא התשובה הנכונה.

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

כדאי להדליק GPU scheduling?

זה לא מאיץ כל מחשב. מדליקים כש-feature שאתם צריכים דורש HAGS; אחרת מתחילים מההגדרה היציבה שיש עכשיו. בהשוואה משנים רק את HAGS, עושים restart, ובודקים מהירות ויציבות באותם תנאים.

כיבוי HAGS מפסיק את השימוש ב-GPU?

לא. HAGS אינו מתג שקובע אם משתמשים ב-GPU; הוא משנה איך מנהלים את העבודה שמועברת ל-GPU. כיבוי לא מבטל rendering רגיל של GPU.

למה ההגדרה לא מופיעה?

נדרשת תמיכה לא רק מ-Windows אלא גם מה-GPU ומה-graphics driver. בודקים את דגם ה-GPU, את גרסת Windows, ואת מידע התמיכה של יצרן המחשב או של יצרן ה-GPU. מספר גרסת WDDM לבדו אינו אומר אם HAGS נתמך.

מה הקשר ל-DLSS Frame Generation?

לפי ההנחיה הרשמית של Nixxes, שימוש ב-DLSS Frame Generation דורש ש-HAGS יהיה מופעל ב-Windows. HAGS עצמו לא מייצר frames; נדרשים גם GPU נתמך, משחק נתמך, וההגדרה בתוך המשחק.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.