ציטוט של Moon-Mage

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

 

af db creid,

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

ציטוט של nec_000

תודה ידידי,

אך הנך נלחם בתחנות רוח. לצערי.

 

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

 

איך אמר,

שימתין ל- architecture day של AMD, אד רבה. למה לא. שישוב לפה לאחר מכן ויסכם לנו מאמר ברמה טכנית/אקדמית

אודות איך עובד cache משולב בליבת עבוד גראפית, אחרי ש- AMD תספר ותסביר לו איך זה עובד לפרוטרוט.

 

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

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

 

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

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

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

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

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

ציטוט של 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 של השבב. להערכתי נועד לאפשר בדומה לאוטוסטרדה של מכוניות,  קישוריות גבוהה מהירה וזמינה לכל

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

 

 

מענה ל- 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, DDR3 - לא היה תיקון שגיאות מובנה בפרוטקול תקשורת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

אכן buck,

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

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

 

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

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

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

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

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

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

 

 

ציטוט של Buck

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

 

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

 

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

 

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

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

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

כפול  ?

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

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

 

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

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

@nec_000

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

היא הרי זאת שפיתחה וייצרה את כל המעבדים ל PS4 ו XBOX ONE.

 

אני רוצה לדייק אותך לגבי עניין ה Cache. כבר בקונסולות היה Cache של 32MB על השבב עצמו, כפי שניתן לראות במצגת על הארכיטקטורה של XBOX ONE:

http://meseec.ce.rit.edu/551-projects/fall2016/3-4.pdf

 

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

 

ועוד משהו, לגבי מה שאמרת בעניין אלגוריטמאים ומתמטיקאים ב AMD, דווקא ל NVidia יש מחלקה בראשות Gary Tarolli ה Lead Designer של 3DFX (ממי שזוכר) שהם אלו גם שהוציאו את ה Ray Tracing (אתה מוזמן לעקוב אחריו בלינקד-אין).

 

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

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

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

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

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

 

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

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

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

 

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

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

 

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

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

 

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

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

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

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

 

 

ציטוט של Moon-Mage

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

 

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

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

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