פריצת דרך בעולם ההאצה הגראפית - cache - עמוד 3 - כרטיסי מסך - HWzone פורומים
עבור לתוכן
  • צור חשבון

פריצת דרך בעולם ההאצה הגראפית - cache


nec_000
 Share

Recommended Posts

ציטוט של Moon-Mage

למעשה כל דבר שקשור בcache הוא פשוט מנחש ובודה מליבו וחצי מהמאמר הזה הוא גם ככה הכפלה\חילוק בשמונה.
וגם אם נניח שהוא עובד בAMD ויש לו את כל המידע הוא כמובן מתעלם מהחסרונות הרציניים שכבר ציינו פה שבאיזשהו שלב אתה צריך להעביר מידע לCache הזה ואתה מקבל צוואר בקבוק מאד רציני ביחס לGDDR6X אם זה קורה ברציפות במספר פריימים מה שיפגע כמובן בחווית השימוש.
עכשיו אני לא אמור שזה גרוע או טוב, אני לא יודע וגם הוא לא יכול לדעת, אבל מה שבטוח שזה פיתרון דיי יצירתי מAMD שעד לפני rdna היו חייבים להשתמש בHBM כדי בכלל להתקרב לנוידיה.

 

af db creid,

אז הנה ההסבר שבקשת ממנו לתת, ברור יותר מכך אין 

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

  • תגובות 39
  • נוצר
  • תגובה אחרונה

משתתפים בולטים בדיון

ציטוט של nec_000

 

התיחסות ל- buck, דבריך בשחור המענה שלי בכחול:

 

זה שכתבת שיש 16 ביטים בטיק של שעון כנראה מסביר מדוע הרכיב כל כך רגיש לרעש, לא ידעתי שהם משתמשים

בתקשורת כלכך מחורבנת על מנת להעביר מידע, מהצד השני אני רחוק מלהיות מומחה לGPUS, יצא לי לגעת מעט

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

את כרטיסי המסך מרעש עם מוליכים.

ב- GDDR6X זה לא 16 ביטים, אלא 4 ביטים שמייצרים 16 רמות סיגנל שונות. 2 בחזקת 4 שווה 16.

להשוואה, GDDR5 זה שני ביטים, שמייצרים איפה 4 רמות סיגנל שונות, ואפילו על זה בשעתו כל כך נלחצו שיגרום

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

פשוט הבינו שזה מספיק אמין גם בלי התיקון השגיאות,  בעיקר משום שבעבוד גראפי אפשר בקלות לספוג שגיאה פה

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

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

מחשבתי  אינהרנטי של מחשב/שרת.  אך פספסו את הפואנטה, שלגראפיקה זה לא משנה אם יהיו כמה שגיאות.

ב- GDDR6 נזכרו ותקנו (ביטלו את התיקון שגיאות).


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

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

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

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

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

את המחשבה האינהרנטית שלנו. לכן אף אחד לא חשב על זה בכלל.

זה שאחרי 30-40 שנה פתאום כבר כן יש אפשרות לממש, יפה מאד שמישהו טרח להזכר ולומר:

 "היי חברים, נראה לי שהגעו לעת שבה יש מספיק real estate בשלב הזה, ליישם את מה שטמנו בבוידעם בשנת

1980. מישהו זוכר בכלל ? "


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

אולי יש מצב שהביצועים ירדו מאוד, אפילו ליותר משהייתי מצפה כי במצב הזה אתה סתם מבזבז את הזמן שלוקח לבאס להיכנס ולצאת מהcache. השאלה אם זה נכון כי אז FPS ממוצע כבר לא אמור לעניין כמו המינימלי כי יכולים להיות דרופים נוראיים בסצינות מסוימות במשחקים בעיקר ב4K. השאלה אם פרקי הזמן הללו רלוונטיים מבחינת מהירות התפיסה האנושית.

אין קשר בין שינויים בין פריים לפריים לזכרון מטמון. זה לא קשור. כל מחזור לציורה של תמונה בדידה, מקבל flash מלא

של כל הזכרון מטמון כולו.  והפלאש המלא נועד לאכסן את מה שהמעבד הגראפי צריך, לטובת השלמת ציורה של

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

לדחיסת תמונה מתחום הוידאו, שגרמו לך לחשוב בשגגה, שיש קשר בין פריים לקודמו בהיבט הזה - שמודדים רק את

הדלתאות בוידאו. אך הנושא הזה קשור לדחיסת תמונה בוידאו, ולא קשור לרנדור CGI. שתי חיות שונות.

 

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

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

לאפשר hi bandwidth באמצעות קו השקה מאד ארוך, שמאפשר  בתורו הרבה מאד interconnects מסביב לכל ה-

real estate של השבב. להערכתי נועד לאפשר בדומה לאוטוסטרדה של מכוניות,  קישוריות גבוהה מהירה וזמינה לכל

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

 

אחת הארכיטקטורות היותר מעניינות ואינטיליגנטיות שראיתי בקריירה:

 

923-block-diagram.jpg

לגבי הארכיטקטורה, די ברור מהתמונה מהיכן הגיע הinfinity לשמות, זה באמת נראה כמו שמונה שוכב. :)

 

יש כאן כמה בעיות שעולות לי מהיכרות עם המבנה הפנימי של ובקרים, נראה לי מהמבנה שלליבות עצמן אסור לכתוב ישירות על אותן הכתובות בcache ואולי אפילו על כל הcache אחרת תיהיה כאן בעיית סנכרון היסטרית שתאט את הכרטיס בדומה למה שקורה עם מנעולים תוכנתיים קלאסיים כשכמה ליבות במעבד מעלות מידע לרגיסטרים שלהן במקביל מאותו איזור כתובות בcache ולפחות אחת מהן כותבת עליו וגורמת לכל הפעולות של כל האחרות להיזרק לפח כי המידע שהן עבדו עליו התיישן. בדיוק המקרה הקלאסי של MESI\MOESI.

 

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

 

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

 

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

 

לגבי  ה4 ביטים, מעניין, אין שום תיקון או זיהוי שגיאות בתקשורת הזו? זה קצת מוזר כי אם כן מדוע רעש פוגע בFPS כשעושים OC לכרטיסים, אם תסתכל על התחרויות בין ערוצי הטכנולוגיה אפילו ההשראה האלקטרומגנטית מהמיקרופונים של חלק מהקריינים מסוגלת לפגוע בתוצאות. קיבלתי את הרושם שהGPU כן זורק פריימים או מאבד זמן על לתקן אותם כשיש הרבה רעש.

קישור לתוכן
שתף באתרים אחרים

קוסם ירח קטונתי,

 

אמתין בסבלנות ללמוד באמצעותך מ- architecture day של AMD 🙏

 

תודה לי נוספת, למדתי לא מעט ממה שכתבת כפידבק מדוע המאמר אינו אקדמאי. תבורך חבר יקר

 

 

 

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

מענה ל- buck,

 

אתה בשחור המענה בכחול:

 

לגבי הארכיטקטורה, די ברור מהתמונה מהיכן הגיע הinfinity לשמות, זה באמת נראה כמו שמונה שוכב. :)

וואלא, האמת שלא שמתי לב בכלל באיור, ונראה לי שעלית פה על משהו. יש בהחלט מצב. 

 

יש כאן כמה בעיות שעולות לי מהיכרות עם המבנה הפנימי של מעבדים ובקרים, נראה לי מהמבנה שלליבות עצמן אסור לכתוב ישירות על אותן הכתובות בcache ואולי אפילו על כל הcache אחרת תיהיה כאן בעיית סנכרון היסטרית שתאט את הכרטיס בדומה למה שקורה עם מנעולים תוכנתיים קלאסיים כשכמה ליבות במעבד מעלות מידע לרגיסטרים שלהן במקביל מאותו איזור כתובות בcache ולפחות אחת מהן כותבת עליו וגורמת לכל הפעולות של כל האחרות להיזרק לפח כי המידע שהן עבדו עליו התיישן. בדיוק המקרה הקלאסי של MESI\MOESI.

 

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

 

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

רקע מקדים:

להבדיל מעבוד CPU אלגוריתם עבוד גראפי הוא מטלה פרללית מרשימה, ללא תלויות מקדימות באותו שלב של

העיבוד. ולכן הבעיה שאתה מתאר אינה קיימת. אין צורך לבצע סגמנטציה של גישה לזכרון באותו שלב כפי שמיד תבין

מההסבר מטה. 

 

בגישה לזכרון אין זה משנה למעבד הגראפי אם הוא עובד מול VRAM או מול מטמון, זה הי נוח ושקוף למעבד,

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

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

או אלפי ליבות עבוד יחדיו וכל אחת מקבלת את פיסת המידע שלה, לרוב פיקסל מתוך טקסטורה.

 

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

הרי פעולת קריאה ולא כתיבה.

פעולת הכתיבה של הליבות המרנדרות נעשית ישירות ל- frame buffer שמרכיב את משטח העבודה שבו

מכינים את הפלט (התמונה). ושוב לא מעניין את הליבות איפה הוא יושב אם זה ב- VRAM או בזכרון מטמון, ההבדל

הטכני הוא רק במהירות הגישה לזכרון. מן הסתם cache מהיר יותר ולכן יוכל לשרת יותר בקשות קריאה/כתיבה ליחידת

זמן. 

 

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

גדולה כוללת, ולסדר הכתיבה אין משמעות. כל ליבה דוחפת לפלט את הפיקסל שהיא אחראית עליו באותה פעימה.

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

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

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

בתמונה הסופית הרי אוביקט קרוב יותר יסתיר מעיננו אוביקט שמצוי מאחוריו. לכן בעיות התנגשות אין פה. לא ברובד

הזה בכל אופן.

 

אחד הבזבוזים הגדולים ביותר ברנדור גראפי הוא שמרנדרים את כל הפוליגונים, גם אלו שמוסתרים

מפוליגונים שנמצאים לפניהם בתמונה. בשנים שאני הייתי בתעשיה לפני כ- 20 שנה, הממוצע עומק שכבות היה

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

כמות הפוליגונים עלתה במאות מונים, ויתכן מאד שיש יותר שכבות ויותר בזבוז. יותר נכון להעריך, שדי בטוח שיש יותר.

 

האלגורתים אומר לכל כך: 

חישבת פיקסל, באת לכתוב אותו, בואי נבדוק מול z buffer (שחושב מראש ככלי עזר),  האם את כותבות אותו

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

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

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

בר דעת, שאם יודעים הכיצד לחסוך את ציורן של כל השכבות המוסתרות, ולצייר רק את השכבה הקרובה ביותר לעדשת

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

בשעתו (לפני כ- 20 שנה) זה היה מגודל 13 שכבות ממוצע טיפוסי.  אלא שהיום זה כנראה הרבה יותר. משמע יש

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

 

אף אחד בעולם עדיין לא פתר הרמטית וסופית את הבעיה האלגוריתמית הזו, היא עומדת תלויה ופתוחה והראשון

שיצליח יזכה לפרס נובל.  אנחנו 50 שנה בתחום ועדיין לא מצאו.  הראשון שימצא את השיטה יגרום למעשה

למאיצים הגראפים  של אותה חברה שתיישם את הפטנט, להכפיל את הכח פי 10 ומעלה. 

אם למשל יש 20 שכבות וחסכנו רנדורן של 19 המוסתרות מאחורה, אז מדובר בהכפלת כח של פי 20.

אם יש 30 שכבות וחסכנו 29, אז הבצוע יזנק פי 30.

 

**מה שכן למדו ברבות השנים זה לבצע כל מני טריקים שקצת מקלים כמו לבצע קודם השוואת עומק מול z buffer

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

ולכן אנרגיה וחום במעבד, אבל עצם פעולת הבדיקה מול z buffer נוטלת (לצערנו) את הזמן החישובי הנחוץ שהולך

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

 

***להערכתי אגב במחשבה מהירה ממש מהשניה הזו, ממש מהרגע, יתכן שהאלגוריתם המודרני שמבצע ray

tracing ב- real time עשוי להיות אלמנט שיעזור פה לפרוץ דרך. כי חלק מהשיטות שמבצעים את האופטימזציה בו

מבוססת על פיקסלים שנצפים על ידי עדשת המצלמה בקישור ישיר מהעדשה. הבנו שיודעים לעשות זאת יעיל מה

שנולד בדור RTX2000.  אותה שיטה שתעזור למצוא את ה- trace ray הישירה לפיקסל, תוכל אולי לסמן רק את מה

שצריך לרנדר ואת מה אפשר להשמיט. באה לי פה מחשבה ב- real time, אבדוק זאת השאר בהאזנה.

 

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

השימוש בזכרון מטמון בדומיין העבוד הגראפי שונה מזה שנעשה במעבד CPU. האלגוריתמים שונים לחלוטין. למעשה

בגלל שמשימת עבוד גראפי היא קבועה ידוע מוכרת ומחזורית, אין צורך בזכרון מטמון העובד בדומה למעבד CPU. קרי

לא  מחזיקים את most frequent accessed pages במטמון ורק מבצעים שחלוף דפים כשצריך, אלא, מתכננים מה

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

היות ועיקר העבודה שצורכת את התעבורה מול הזכרון במעבד גראפי היא קריאת הטקסטרות ופרישתה על גבי

הפוליגונים, אפשר לתכנן חכם, שזה לקחת את הטקסטורה עצמה ולהכניסה לזכרון מטמון, ולרנדר אותה ישירות

בתוך הזכרון מטמון ומבלי הצורך לכתוב אותה ל- VRAM.

 

לסכם:

א. מתודת העבודה מול מטמון בעבוד גראפי שונה ממתודת העבודה של CPU רגיל, ב- CPU זה page swap לפי hit או miss.

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

ג. מה שמאפשר לעיבוד הגראפי לעבוד בצורה מתוכננת,  היא העובדה שהצורת עבודה שלו מובנת סדורה וצפויה על

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

הרבה יותר לממש משהו יחודי ויעודי לאותו שמוש. משמע נצילות גבוה מאד בעבודה מול cache יעודי.

 

לגבי  ה4 ביטים, מעניין, אין שום תיקון או זיהוי שגיאות בתקשורת הזו? זה קצת מוזר כי אם כן מדוע רעש פוגע בFPS כשעושים OC לכרטיסים, אם תסתכל על התחרויות בין ערוצי הטכנולוגיה אפילו ההשראה האלקטרומגנטית מהמיקרופונים של חלק מהקריינים מסוגלת לפגוע בתוצאות. קיבלתי את הרושם שהGPU כן זורק פריימים או מאבד זמן על לתקן אותם כשיש הרבה רעש.

עד ארכיטקטורת GDDR5, שקדמו לה SDR, DDR1, DDR2, - לא היה תיקון שגיאות מובנה בפרוטקול תקשורת

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

בשלב התחלתי, כארטיפקטים (בדר"כ בצבע ירוק), משום שהשגיאה הטפוסית היתה מאבדת ערך כזה, שהדיפולט

הפרשני שלו בפורש התמונה = DAC הוא green color. ובמקרה שהתקלות היו עולות יתר על המידה הדבר היה

מגיע לתקיעה - hard freeze. במעבר לארכיטקטורת לראשונה שינו את הפרוטוקול תקשורת של הזכרון

בצורה משמעותית, והעלו את רוחב הפס פי 2 מ- פר קלוק פר פין. 

חשבו שהדבר יוביל לטעויות זיהוי ושגיאות של הבקר, כמו גם חשבו באותה עת ש- ישמש לעוד יישומים ולא רק

למאיצים גראפיים. אז הטמיעו error correction methods שמשמעותם בכרטיס מסך היתה, שכל עוד יש מעט

שגיאות הבקר תיקן אותם (תמורת אבדן ביצועים כמובן = retransmission). אבל לא קבלנו ארטיפקטים על המסך

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

עוברים למצב של hard freeze. קרי לא היתה אזהרה מקדימה לקריסה בשונה מהדור הקודם, שנתן התראות וסימנים

מקדימים בדמות ארטיפקטים ירוקים על המסך.

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

של פיקסל מחושב בתמונה, אבל ישנן שגיאות שהן חלק מקוד אלגוריתם ריצת העבוד עצמו (לא של יצוג הפיקסל) ואז

הן עוצרות את המעבד הגראפי ומובילות ל- hard freeze.

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

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

 

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

 

טוב, תודה, עכשיו ברור לי יותר איך מעבד גראפי עובד. זו באמת צורת עבודה בזבזנית ושונה מאוד ממה שאני מכיר.

נערך על-ידי Buck
קישור לתוכן
שתף באתרים אחרים

אכן buck,

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

מיטב המוחות מצויים בתחום הזה, מסיבות רבות וברורות, והיא נוטלת נתח ארי בכלכלה המחשובית.

 

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

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

אלגוריתמיים הוא אדיר ולכן עובדים על זה רבות. היו עשרות רבות אם לא מאות של פריצות דרך בתחום במהלך 40

השנים האחרונות.


אני לבטח לא מכיר את כולן או שולט בכולן, במיוחד כיום שכבר הרבה שנים נמצא מחוצה למעגל הזה של אלגוריתמי בעבוד גראפי (עברתי עם השנים לניהול), אז מטבע הדברים מחליד וצריך כדי להכנס שוב, לעשות הרבה

מאד השלמת חומר של כל מה שרץ, פותח, והומצא, מאז שיצאתי מהתמונה. 

 

 

ציטוט של Buck

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

 

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

 

טוב, תודה, עכשיו ברור לי יותר איך מעבד גראפי עובד. זו באמת צורת עבודה בזבזנית ושונה מאוד ממה שאני מכיר.

 

אגב, נוידיאה עשתה משהו בנושא. בדור 1000 לראשונה היא פיתחה טכניקה שנועדה לחסוך עבודת עבוד במוד .

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

הצילום, קרי מיקום העין השניה הוא רק 5 ס"מ הצידה מהעין הראשונה, אזי מדוע לרנדר את כל התמונה מחדש ולעבוד

כפול  ?

נוידיאה פיתחה איפה ב- 2016 רנדור במוד החוסך 80% מהרנדור של העין השניה. כך שלמעשה במחיר 1.2

רינדורה של תמונה בודדת, היא מסוגת לרנדר שתי , כאשר כל אחת מתאימה מבחינת הזוית לעין הנכונה.

 

אז יש משהו במה שחשבת עליו ונוידיאה כבר עשתה עבודה בנושא וממשה אותו אפילו. מאיצי מסך מדור 1000

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

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

^בעניין הזכרון מטמון בקונסולה המלונקקת,

וככל שידי משגת בזמן תגובה מהיר/קצר, הזכרון מטמון בקונסולה הוא המטמון הרגיל הדומה לזה של CPU,

או בעצם כמו שמשמש ב- ליתר דיוק, ולא המטמון dedicated אשר משמש אך ורק את המרכיב הגראפי, קרי

זה שמשוריין רק לחישובי בניית התמונה וכפי שהטמיעו באופן חלוצי ב- RDNA2. שזו חיה אחרת לגמרי.

 

ברקע הדברים ניזכרה,

במעבדי CPU מקובל (היום) שיש 32MB מטמון למתומני ליבות, מאז ריזן של 2019 בעצם,

כאשר הרף הקודם לכך היה 16MB למתומני ליבות, מאז 2009.

 

ריזן הראשון של 2017 הוא 16MB.

ואצל אינטל היה מקובל 16MB זכרון מטמון במעבדים שלהם 8 ליבות (בפלטפורמה HEDT).

 

מדובר כאן ביחס של 2MB cache per במעבדים.

יחס שהיה מקובל מאז icore של 2009 באם הולכים מספיק אחורה על ציר הזמן. 

 

בקונסולה המוזכרת שלנקקת יש 8 ליבות שמצריכות בעת המודרנית כאמור 16MB cache רק עבור שמוש ה- CPU. 

כנראה היתרה בגודל עוד 16MB משועבדת לטובת הגראפיקה. זו הערכתי הזריזה, אבל זה , אז צריך לצלול פנימה

כדי להבין איך הם חלקו איזה resource למה ומה אופן העבודה ופה אני פחות מעורה מבחינת עניין. 

*אולי זה shared cache על מנת לשפר נצילות ככל שניתן, למי שצריך יותר באותו רגע,  CPU או GPU.

 

 

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

ציטוט של Moon-Mage

למעשה כל דבר שקשור בcache הוא פשוט מנחש ובודה מליבו וחצי מהמאמר הזה הוא גם ככה הכפלה\חילוק בשמונה.

 

תימצות  גאוני של כל ה"מאמר"  הפותח בדיון הזה.

אבל היי, מי שטוב לו, לא אפריע חלילה .....

עימכם הסליחה !

 

קישור לתוכן
שתף באתרים אחרים

הצטרפ/י לדיון

בשלב זה תוכל/י להצטרף לדיון, ולאחר מכן להצטרף לקהילה שלנו. אם כבר יש לך חשבון אצלנו, אנא התחבר/י עכשיו על מנת להגיב תחת שם המשתמש שלך.
לתשומת לבך: התגובה תופיע לגולשים לאחר אישור של צוות הנהלת הפורומים.

אורח
הוסף תגובה

×   התוכן שהודבק הוא עם עיצוב.   הסר עיצוב

  Only 75 emoji are allowed.

×   הקישור שלך הוטמע אוטומטית.   הצג כקישור רגיל

×   התוכן הקודם שלך שוחזר אוטומטית.   נקה הכל

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
  • צור חדש...