RDNA3 - מידע ראשוני לקראת שנה הבאה - עמוד 2 - כרטיסי מסך - HWzone פורומים
עבור לתוכן
  • צור חשבון

RDNA3 - מידע ראשוני לקראת שנה הבאה


nec_000
 Share

Recommended Posts

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

נניח שאני מריץ מספר instances של משחק מסויים. האם התהליכים השונים ילחמו על מקום ב-CACHE?

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

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

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

זה לא עובד ככה איש המערות. תהליכים לא "נלחמים" על מקום ב- cache. cache משרת ברגע נתון רק את התהליך

שרץ באותו רגע על ה- GPU. ברגע נתון יכול לרוץ רק תהליך אחד. הדבר דומה למעבד CPU, אסבירה בהרחבה:

 

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

תהליך אחד שמקבל אליו גישה בלעדית. במיוחד משחקים וסימולטורים שזו משימה שהיא realtime מטבע

הדברים.  זהו סגנון העבודה הטיפוסי בהאצה גראפית. 

 

אבל אנו מדברים על מצב שהגישה הבלעדית הזו מבוטלת.

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

דווקא אלא חישוב מתמטי אצוותי שמבקש את ה- GPU, אזי בדומה לחלוקת עבודה (בליבה של מעבד), כל פעם

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

 

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

בפעילות של המשימה האחרת, ואחר כך עובר לבאה בתור, הכל לפי האופן שבו מערכת ההפעלה מתזמנת עבורו את

הפעילות ואת חלוקת הזמן.

 

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

יושב ב- vram (באם בוצע pre cache שלו ל- vram שזה תלוי יישום). או שהוא נטען ל- cache על בסיס קריאה
per call basis (כמו במעבד CPU).

 

במידה ומערכת ההפעלה מנהלת את שני התהליכים שישבו בו זמנית ב- vram, קרי עשתה לשניהם pre caching

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

vram הוא ה- cache של ה- .

 

המעבד GPU יעבוד כל פעם מול המקטע שבו יושב ה- stack של אותו יישום שכרגע מצוי בעת ריצה. מה שנקרא מול

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

 

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

הקרובים של ה- GPU, או, מה שהוא ב - most frequently accessed בשיטת נהול paging.  תלוי אלגוריתם נהול

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

 

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

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

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

 

כמו כן בכל הכרטיסים יש cache. השאלה מה גודלו:

בכרטיסים עד ל- RDNA2 נפח ה- cache הוא מטיפוס 5-10mb.  מ- RDNA2 הנפח קפץ ל- 128MB.

 

ה- cache פועל באופן זהה בין שרץ ישום אחד במערכת ההפעלה, קרי stack בודד של ישום בודד, או מורצים הרבה

ישומים, קרי סגמנטציה של הזכרון כך שכל סגמנט מקבל את ה- stack שלו.

 

גלישות מ- cache בעת ריצת התהליך (הפרוסס) מוסטות לאחסון ב- vram, שזו ההרכיה הבאה ובאמצעות paging.

גלישות מ- vram באותו האופן מוסטות ל- הכללי עם paging וכיוצא בזאת, שזו ההרכיה הבאה אחריו.

וגלישות מ- גולשות כידוע ל- disk באמצעות paging וכן הלאה וכן הלאה. וכך זה בכל כרטיס מסך באשר הוא

ולא שונה ב- RDNA2 מכל מקרה אחר. אלא שכשיש יותר cache מטבע הדברים, אירועי הגלישה בין on die cache

ל- Vram יורדים בכמותם.

 

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

יש L1 cache, לאחריו L2, לאחריו L3, לאחריו , לאחריו דיסק, וכיוצא בזאת... ומעבד בדר"כ מג'נגל בין עשרות

(אם לא מאות) תהליכים שהמערכת הפעלה זורקת אליו כל הזמן. והוא context switch של כל ה- buffers

שלו בכל פעם שהוא מבצע מעבר לטפל בפרוסס אחר.

 

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

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

של 7 רמות כנראה החל מעוד שנתיים.

 

 

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

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

לצורך העניין, הפעלה של 5 פעמים world of warcarft או 4 פעמים 3.

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

לא נכון.

לא הבנת, אסביר שוב יותר פשוט:

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

 

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

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

ב- pipe line וב- stack. רק אחד.

 

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

ההספק של המערכת הוא -> ההספק שלה כמו שרץ עליה פרוסס בודד. 

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

 

אני חושב שהבנתי מה מבלבל אותך,

אתה בטעות סובר שה- stack יושב ב- cache. אבל לא כך. ה- stack יושב ב- vram או ב- .

בדיוק כמו במעבד CPU. בכל context switch הכל purged. כל הבאפרים והזכרון מטמון גם.

 

במקרה של האצה גרפאית זה אותו הדבר, ה- stack יושב או ב- RAM

(או ב VRAM אם היה לו מקום שם) זה הכל.

 

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

 

 

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

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

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

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

מה שאני מנסה להסביר, זה שאם יש לך cache של רק 5-10MB, כמו שיש בכל הכרטיסים בעולם,

או יש לך cache בגודל 128MB, התוספת הזו של ה- cache לא יכולה לפגוע בשום צורה שהיא בביצועים,

לכל יותר לשפר, אבל בטח שלא להזיק.

 

השאלה שלך צריכה להיות מנוסחת אחרת:

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

ברוחב פה של הזכרון VRAM ולהיות כזו -> מה קורה במקרים שבהם רוחב הפס של ה- VRAM קטן יותר לעומת

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

 

התשובה היא שבוודאי שזה משפיע, אבל לא בהיבט של מה שתארת (ריבוי תהליכים) אלא בהיבט האלגוריתמי:

לא כל אלגוריתם מרוויח מ- cache. ומי כמוך איש data bases מכיר, שאם תעשה פעולה על ה- DB מסוג כזה

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

נתון ?

כמו למשל פעולה של להוסיף לכל תא בודד ב- DB ערך אחד בנוסף. עוד עמודה נגיד. פה cache לא עוזר בכלום.

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

 

משמע,

האישו פה אינו ריבוי תהליכים בשאלתך, אלא סוג האלגוריתם.

 

עכשיו,

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

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

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

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

ובגלל זה הטמיעו אותו מלכתחילה.

 

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

ואז רוחב הפס מול ה- VRAM יהיה מה שידבר.

 

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

שאלת על משחקים ספציפית ? 

אז במקרה של משחקים (ריבוי משחקים) מה שתארתי לך זה מה שיקרה. הריבוי תהליכים אינו רלוונטי לשאלה והוא

יתנהג היטב בדיוק כמו שרץ משחק בודד. מכיוון שה cache אדיש ל- context switch. הוא אינו קשור לנושא.

 

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

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

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

 

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

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

רבות על אותו מקטע קטן, ולכן לא ברור לנו שה- cache בכלל עוזר.

 

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

 

 

סיכום:

א. משחקים ?

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

 

ב. לא משחקים ?

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

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

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

 

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

ציטוט של captaincaveman

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

נניח שאני מריץ מספר instances של משחק מסויים. האם התהליכים השונים ילחמו על מקום ב-CACHE?

 

הנה נוסח השאלה שהיית צריך לשאול:

"מה שמסקרן אותי איש המערות לדעת, זה האם הפשרה של RDNA2 ברוחב פס לטובת מטמון on die,

משפיע על ריבוי תהליכים ?   במקרה של משחקים ולא רק משחקים....

ובכלל איך היא משפיעה ללא קשר לריבוי תהליכים".

 

התשובה כפי שתארתי קודם היא:

א. שזכרון מטמון אינו משפיע על ריבוי תהליכים, הוא משפיע על "סוג היישום" המורץ.

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

    ש- cache תפור עבורו כמו כפפה ליד.

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

 

 

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

מי אחראי למלא דברים ב-CACHE של כרטיס המסך? מרגיש לי שחייבת להיות איזושהי התייחסות ל-process שהכניס את המידע לכתובת בזיכרון...

האם process אחד יכול לגשת למידע ש-process אחר גרם להכנסתו ל-cache?

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

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

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

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

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

המחיר הוא צריכת רב.

 

ה- on die cache בדומה לאוגרים, purge בכל context switch. למעשה, אם לא pre caching או מאלצים

את התהליך לשמור את ה- stack שלו ב- vram, אז ה- vram purge גם הוא. למעשה vram הוא כולה cach

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

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

שהוא שמו הישן.

 

עכשיו,

כדי ש- stack של תהליך ישאר ב- vram מלכתחילה, למרות שהוא יוצא כל הזמן אם לא תאלץ אותו אחרת, צריך שמערכת

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

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

התהליכים יהיו מאוכסנים יחדיו ב- vram ולא ב- , בהנחה שיש לכולם מקום כמובן באותה עת. 

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

קרי למזער אירועי context switch להתרחש מהרמה של vram ומעלה, ולא מהרמה של ומעלה.

לחסוך זמן בכל context switch כשהוא מתרחש ולחסוך את תקורתו.

 

כדי להבטיח שהובן היטב הנושא, נסבירה, שה- cach on die הוא קטן מדי על מנת לעשות בו את אותו הטריק שעשינו ב- VRAM,

קרי להעלות עד אליו את הישומים וה- stack, כך שכולם ישבו בו בדומה לאיך שהם יושבים היום ב- vram הענק.

ישומים מהסוג שרץ על GPU , לא יכולים להכנס בנפח קטן, אפילו כמו 128mb.

 

אם מתי שהוא בעתיד הרחוק מאד, ה- cach on die יתפח למימדי ענק של ג'יגות, ויהיה מסוגל לאכסן את הדרוש שיושב

היום ב- vram, או אז אולי יהיה ניתן להעלות את ההררכיה כך שהיישומים עצמם וה- stack ישבו כל כולם באותו cach on die.

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

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

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

 

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

ציטוט של captaincaveman

האם process אחד יכול לגשת למידע ש-process אחר גרם להכנסתו ל-cache?

 

אני חושב שיורד לסוף דעתך ומבין את שאלתך טוב יותר, מעריך בזהירות הנדרשת, שמבין אולי מה מבלבל

אותך מעולם המעבדים וניסית להקיש לעולם ה- GPU, אזי אסביר גם את זה:

 

בשונה ממעבד CPU (מודרני) שבו ה- L3 cach מאפשר העברת מידע **בין הליבות** של המעבד, קרי בין ליבה

ראשונה נגיד לליבה רביעית, כך שכל אחת מהן מריצה פרוסס זר, ה- on die cach במאיץ גראפי משותף רק לליבות

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

 

זאת מכיוון שה- cach במאיץ הגראפי יושב בהררכיה, במקום כזה שמשרת רק את ליבותיו של המאיץ הגרפאי, ואל

לנו לבלבל עם ליבות של GPU עם ליבות במעבד CPU - המאיץ הגראפי בכל רגע נתון, לא משנה שיש לו אלפי ליבות,

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

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

 

ולכן מידע/משתנים יכולים לעבור בין תהליכים שונים, רק ברובד הררכיה שמתאים להם, קרי או דרך ה- במקרה

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

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

ובכוונת מתכנן, להחליף משתנים דרך ה- VRAM.

 

כי אם לא, אז יחליפו דרך .

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

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

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

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

 

אז קודם להגדרות:

באותו משחק, אין ריבוי תהליכים ב- GPU. המשחק זה תהליך אחד שה- GPU מריץ.

ה- GPU מריץ פרוסס של ציור המסך והפלט שלו הוא המוניטור של המחשב.

 

הדרך היחידה לאלץ ריבוי תהליכים ב- GPU, באם זה רק באמצעות משחקים שונים, זה להריץ כמה משחקים בו זמנית,

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

למשאב ה- GPU , בגלל שמדובר בתהליך מסוג real time.

 

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

לא תעשה realtime.

 

לנושא ה- cach אין קשר לכמה ישומים מתבקשים להתבצע על ידי ה- GPU, שכן כפי שהוסבר, בכל זמן נתון המאיץ

מריץ רק את אחד מהמשחקים, וה- cach משמש את אותה ריצה ספציפית. וברגע שהמעבד GPU עובר לטפל במשחק

הבא, ה- cach ישרת את המשחק הבא וחוזר חלילה.

 

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

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

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

הבנת הנקרא...

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

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

 

לדוגמה:

 

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

GPU מריץ את הגראפיקה המצוירת על המסך, לא את מנוע המשחק.

משחק אחד יעביר מידע למשחק שני, ברובד שאינו גראפי, אלא ברובד האפליקציה שמריץ ה CPU.

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

 

מנסה להסבירך מכוון אחר:

ה- GPU בשרשרת העבודה, יושב בקצה האחרון בשרשרת -> הוא רק מקבל בקצה גמר המשימה, 

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

 

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

הא ותו לא.

 

אכתוב זאת הכי פשוט וברור:

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

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

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

את אמרתו, להלן הפלט, לכוון המסך.

 

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

אבל למה שהמטמון יהיה קשור לרוחב פס?

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

המטרה של המטמון היא לוודא שיחידות העיבוד לא נחות בפעולות של I/O.

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

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

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

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

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

  Only 75 emoji are allowed.

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

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

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

 Share


×
  • צור חדש...