מה הסיכוי ש VULKAN יהפוך לסטאנדארט לדעתכם

[Sargon]

DX 12  וVULKAN אמורות לתת אותה רמה של ביצועים(אם מתעלמים מבעיות דרייבר).

הסיבה שצריך את Vulkan זה בגלל שOPENGL הכי מתקדם עובד כמו DX11, כלומר הוא לא נותן גישה לתיכנות יותר LOW LEVEL.

אז מכיוון שOPENGL כבר לעולם לא ייתן ביצועים כמו DX12, יש צורך בVULKAN למכשירים שאין בהם DX(למעט מכשירי Apple ששם יש להם את METAL).

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

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

 

[OvOnoob]

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

 

מישהו מוכן להסביר בכמה מילים מה ההבדל בין low level לhigh level? ובמה זה מתבטא? ולמה Low level עדיף?

 

תודה.

[coch]

נראה לי שזה מושגים מעולם התכנות. ניחוש פרוע - כנראה High הכוונה לשפה עילית.

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

היה לי קורס Java מתנה ( כנראה ברמה של תיכון ) שסיימתי תואר שני, אני גאה בעצמי שלא הגעתי לאף שיעור וקיבלתי

תעודונת כזו בסוף

 

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

שיורדים לשפות שהם לא עילית ? או שאין קשר ?

 

 

[Idanh]

@coch אחלה ניחוש 

[djelectric]

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

 

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

 

 

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

 

[NAND]

רואים שהכרטיס חנוק.

למרות מהירות שעון של 1266Mhz זה בדר"כ בממוצע הרבה מתחת ל-1200Mhz, ולדעתי זו הבעיה. 

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

[coch]

צריך לקחת בחשבון לטובה ולרעה משהו - הפריימים המקסימליים מגיעים לאיזור ה 250 בזמן שרוב המשחק

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

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

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

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

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

 

ההבדל הגדול ביותר ( והמורגש ביותר ) לגיימרים זה בעצם המינימום פריימים. וזה למה גם לצורך העניין 1070 נניח ברזו' של 1080P

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

המורגשות ביותר ( חוץ ממשחקים שהפורט עלוב ) נובע מהפריימים המינימליים.. לכן גם חשוב לציין לרעה את Doom שבעצם Vulkan

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

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

 

נקודה למחשבה האם באמת Vulkan יראה מינימום פריימים גבוהים מהרגיל. בינתיים יש רק את Doom וזה לא מדד טוב.

[Idanh]

ציטוט של coch

נקודה למחשבה האם באמת Vulkan יראה מינימום פריימים גבוהים מהרגיל. בינתיים יש רק את Doom וזה לא מדד טוב.

יש גם את DOTA2... אבל המשחק הזה נותן 60FPS גם על Intel Graphics חחח.

והבנתי ש AMD לוחצים שב Ashes of Singularity תהיה תמיכה ב Vulkan, המשחק היחידי שהראה עליונות של 480CF על 1080.

[Gonen Beneish]

Senior Engine Programmer at id Software

 

“DirectX 12 and Vulkan are conceptually very similar and both clearly inherited a lot from AMD’s Mantle API efforts. The low level nature of those APIs moves a lot of the optimization responsibility from the driver to the application developer, so we don’t expect big differences in speed between the two APIs in the future. On the tools side there is very good Vulkan support in RenderDoc now, which covers most of our debugging needs. We choose Vulkan, because it allows us to support Windows 7 and 8, which still have significant market share and would be excluded with DirectX 12. On top of that Vulkan has an extension mechanism that allows us to work very closely with AMD, NVIDIA and Intel to do very specific optimizations for each hardware.”

[nec_000]

coch בוקר אור,

 

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

Low level זוהי כאמור גישה תכנותית ברמת קוד נמוכה יותר.

 

ישנן רמות שונות של how low can you go כאשר הרמה הנמוכה ביותר היא תכנות ישיר בשפת מכונה,

מה שמכונה machine language . בתכנות מעבד כללי CPU עושים זאת עם שפת assembler , השפה הכי נמוכה בה אומרים

למעבד פקודה ברמת בסיס כגון:

העתק מידע מאוגר כלשהו במעבד, למשל אוגר DX במעבדי 8086, להעתיק את תוכנו לאוגר אחר (או לזכרון הכללי).

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

 

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

שמעלה, אלא מדברות עם מערכת ההפעלה, ואת הפעולות שהן מבקשות לבצע, הקומפיילר במערכת ההפעלה מתרגם ל- machine language.

 

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

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

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

 כך שה- machine language נכתב על ידי הקומפלייר לא יעיל לעומת כתיבה ישירה במיקרוקוד.

 

זה בדיוק מה שקורא כאשר מתכנתי משחקים יוצרים קידוד שפונה גראפית ל- API, כמו למשל direct X.

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

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

בדרך לא מעט מיכולות המעבד הגראפי ומיכולות ה- CPU גם. ולשם כך נולדו תקנים מודרניים של שפת קוד low level לעיבוד

גראפי.

 

כאן מעבר לכתיבה בשפה שהיא low level מאפשר למפתח האפליקציה לגשת באופן מיטבי וישיר לחומרה, ולכתוב את הרוטינות

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

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

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

 

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

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

בנפרד.

 

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

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

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

 

מערכות שונות בשימושים שונים נכתבות בשפות עיליות או בשפות נמוכות. מערכות זמן אמת בדר"כ יכתבו בשפות low level

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

עילית.

 

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

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

 

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

נ"מ כדוגמתה של כיפת ברזל אשר תהא דוגמא טובה לכך:

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

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

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

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

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

 

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

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

[omertgm]

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

[djelectric]

משתוללים? מאיזו בחינה?

[omertgm]

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

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

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