
לינוקס 7.3 יתמודד טוב יותר עם אזילה של זיכרון הווידאו
טלאי ליבה שמשנים את הדרך שבה מנהל ההתקן של AMD מתמודד עם אזילה של זיכרון וידאו אושרו ב-upstream ומיועדים ללינוקס 7.3: משחקים ייתקעו פחות וזמני הפריים יהיו יציבים יותר.
טלאי ליבה שמשנים את התנהגות מנהל ההתקן של AMD כשזיכרון הווידאו אוזל אושרו ב-upstream והוכנסו לתור לקראת לינוקס 7.3 — כך עולה מרשומה שפורסמה ב-17 באוגוסט בבלוג pixelcluster. העבודה ממשיכה מאמץ קודם לשיפור ניהול ה-VRAM במשחקים.
הפיזיקה של אזילת VRAM
באופן תיאורטי, מחסור ב-VRAM אמור לפגוע בביצועים ולא ביציבות: מנהל ההתקן מאפשר ליישום לבקש יותר זיכרון ממה שיש בכרטיס, והעודף עובר לזיכרון הראשי. דווקא ההעברה הזו היא צוואר הבקבוק. בחיבור PCIe 4.0 x16 מעבירה האפיק מעט פחות מ-32 GiB לשנייה, כלומר כ-32.2 MiB למילישנייה. בקצב של 30 פריימים לשנייה עומדים לרשות כל פריים 33.3 מילישניות, ולכן הכמות המקסימלית שהמעבד הגרפי יכול למשוך מהזיכרון שנפלט היא כ-1,075.5 MiB — בקושי יותר מ-1 GiB. אם פריים אחד צריך יותר מזה, 30 פריימים לשנייה פשוט בלתי אפשריים.
מטמונים סופגים חלק מהעלות. מדידות על RDNA3 מראות השהיה זהה לזיכרון במעבד ולזיכרון בכרטיס כל עוד המאגר נכנס למטמון L2 בגודל 6 MB; בהחמצה של המטמון ההשהיה של זיכרון המעבד מגיעה לכ-2,400 מחזורים לגישה. שליפה דרך PCIe עולה פי 7.3 בערך מהחמצה במטמון Infinity Cache ופי 4.6 לעומת שליפה מה-VRAM.
תקלת היציבות: קיפאון בנעילת הליבה
אזילה פוגעת גם ביציבות. RADV מדפיס "Not enough memory for command submission" כשהליבה מחזירה -ENOMEM, אף שכל הקצאות הזיכרון הצליחו. הסיבה היא קיפאון קלאסי מסוג ABBA: שליחה אחת מנסה לפנות הקצאה שנעולה בידי אחרת, ובמקביל לשליחה השנייה דרוש זיכרון המוחזק בידי הראשונה. הליבה יודעת לזהות קיפאון כזה ולנסות שוב, אבל רכיב העזר drm_exec לא היה בשימוש ב-TTM, שכבת ניהול הזיכרון המשותפת של המעבד הגרפי. טלאים מ-2024 מעולם לא נכנסו, ולכן המפתח העביר אותם לליבה עדכנית ותיקן את יתר הבאגים — שבוע שלם של מרדף אחרי תקיעות שהופיעו שלוש דקות לתוך עומס כבד על ה-VRAM.
מאגרי סריקה ופינוי של 4 GiB
מדידות פרופיילינג הראו שרוב הזמן שאבד לא נוצל לרינדור אלא להעברות זיכרון ב-SDMA. המקרה החמור ביותר הוא המאגר הנסרק אל הצג: חומרת הצג עוקפת את הזיכרון הווירטואלי וזקוקה לעמודים רציפים פיזית, בעוד שאלגוריתם הפינוי הוא לולאת LRU פשוטה שמתעלמת מאילוצים פיזיים. בפועל פונו עד 4 GiB של VRAM כדי לפנות מקום לתמונות סריקה של כ-32 MiB נתוני פיקסלים כל אחת; עצם העברת הנתונים האלה עולה לפחות 130 מילישניות. שלבי האטה קשיחה ורכה אמורים לעצור את תנועת הזיכרון ההדדית הזו.
מה זה נותן בפועל
עם ההיוריסטיקות האלה, Indiana Jones: The Great Circle שביקש 9 GiB על כרטיס עם 8 GiB הגיע לממוצע של 19.6 מילישניות לפריים. הכפלת עודף הזיכרון הגבירה מאוד את השונות בזמני הפריים, עם קפיצות מעל 33.3 מילישניות וממוצע של כ-29.8 מילישניות. הליבה גם מכבדת את ההרחבה VK_EXT_pageable_device_local_memory ואת vkSetDeviceMemoryPriorityEXT, שמאפשרות ליישום לדרג איזה זיכרון בטוח יותר לפינוי; vkd3d-proton כבר מתרגם את ממשקי הרזידנטיות של D3D12 למנגנון הזה. העבודה זמינה כבר בערוצי Stable ו-Preview של SteamOS.
SiTech — פיתוח אתרים בכוח ה-AI
אנחנו בונים אתרים מהירים ומודרניים ומשלבים AI בתהליכי עבודה אמיתיים. יש לכם פרויקט או שאלה? נשמח לעזור.