რას ნიშნავს DirectX 12 გეიმერებისა და დეველოპერებისთვის

[OpTiMeR]

Windows 10-ს გამოშვებამ დაგვანახა, რომ ფართო PC გეიმინგის პუბლიკას საქმე ექნებოდა დაბალი-დონის (low-level) გრაფიკულ API-სთან (Application Programming Interface). აქედან მოყოლებული, თავდაპირველად AMD-მ წარგვიდგინა Mantle API 2013 წელს, მას შემდეგ კი უამრავი დისკუსია გაიმართა იმის შესახებ, თუ რამხელა წინ გადადგმული ნაბიჯი იქნებოდა დაბალი-დონის API გეიმერებისთვის და რაოდენ დიდ მატებას მოგვცემდა ის. იყო მოსაზრებები, რომ ეს გრაფიკის რევოლუცია იქნებოდა, ისევე როგორც მარკეტინგული მანიპულაცია. ეს სტატია კი შეეხება იმას თუ რა არის რეალურად DX 12 და სად ვნახავთ კონკრეტულად სანატრელ მატებებს.

იმისათვის რომ ავხსნათ თუ რა არის ის და რატომ არის, მცირე გადახვევა გავაკეთოთ და ჩავუღრმავდეთ სხვადასხვა API-ს დიზაინების გადაწყვეტას, ისტორიულ განვითარებას, რომელიც ამ ხელოვნებას უძღვოდა წინ. ეს ტექნიკურ ცოდნასაც შეგვმატებს.

თავიდანვე ვთქვათ, რომ ეს სტატია არ შეეხება მხოლოდ თანამედროვე, ვარსკვლავურ ვიდეო დაფების განხილვას DX 12-ზე, რომლითაც კომპანიები თავს იწონებენ და თაროზე შემოდებისას დიდი შრიფტით მიაწერენ ხოლმე ახალი feature-ების შესახებ. არც ისე წვიმს როგორც ქუხს და ნუ შეშინდებით, ყოველ შემთხვევაში თუ თქვენ ხართ ადამიანი, რომელსაც ყოველი ახალი API-ს რელიზის შემდეგ შეუძლია საკუთარი იდეების მასში იმპლემენტაცია ან/და იმაზე უკეთესი დაბალი/მაღალი-დონის ინტერფეისის შექმნა, ვიდრე DX 12 არის, მაშინ საქმეს შეუდექით, ტყუილად მნიშვნელოვან დროსაც ნუ დაკარგავთ. მაგალითად, დეველოპერებს, რომელთაც DX 12-ზე გადასვლა არ უნდოდათ უკვე შეეძლოთ DX 11.3 ვერსიაში საკუთარი იდეების ჩატენვა... ისიც თავიდანვე ვთქვათ, რომ ახალ ინტერფეისებს უფრო მნიშვნელოვანი გავლენა მომდევნო წლებში ექნება, ვიდრე ეს დღესაა, პირველი ტალღის Direct3D 12 თამაშებზე.

 

DirectX-სა და ზოგადად ინტერფეისების მოკლე ისტორია

სანამ DX 12-ს დეტალებში გავერკვეოდეთ, მანამდე მცირე ზედაპირულ ცოდნას უნდა ჩავუყაროთ საფუძველი. პირველ რიგში, საერთოდ რა არის 3D API? - როდესაც თავდაპირველად მარკეტზე 3D აქსელერატორი ნაწილები გამოვიდა (პირფერობას მოვეშვათ და ვიდეო ადაპტერები), პროგრამერებისთვის საჭირო გახდა რაღაც ინტერფეისი, რომლის დახმარებით მუშაობაც მარტივი იქნებოდა და ზ/ხსენებულ ნაწილების შესაძლებლობების ბოლომდე გამოვლინებას შეუწყობდა ხელს. თავდაპირველად ამ ყველაფერს თავი 3DFX Interactive-მა მოაბა და შექმნა პირველი ინტერფეისი. თავიდანვე ცხადი იყო, უკვე არსებულს წინ დიდი მომავალი ელოდა. მომავალში ამ საქმეს განვითარების გზაზე OpenGL და DirectX აყენებს.

იმ დროის ვიდეო ადაპტერები საკმაოდ მარტივი მოწყობილობები იყო, ვიდრე ისინი დღეს არიან. მაშინ რეალურად API იმისათვის სჭირდებოდათ დეველოპერებს, რომ ამ მოწყობილობებს ეკრანზე მარტივი ტექსტურები ებეჭდა, როგორიცაა სამკუთხედი და სხვა; სინამდვილეში სწორედ ეს ევალებოდათ მაშინდელ ადაპტერებსაც. აქედან მოყოლებული მოწყობილობების შესაძლებლობები არანორმალური სიჩქარით განვითარდა და შესაბამისად ეს ვერ მოხდებოდა, თუ პროგრამირების ინტერფეისებიც არ განახლდებოდა.

ყველაფრის მიუხედავად, მაღალი-დონის (high-level) ინტერფეისები დღესაც მარტივ პრინციპზეა დაფუძნებული. ის პროგრამერებს ეხმარება, რათა ნაკლებად იყვნენ შეწუხებულნი მოწყობილობის-მხარეზე (ინგლისურად უკეთ ჟღერს, hardware-level details). მაღალ-დონესთან მუშაობა საკმაოდ მოსახერხებელიც კი არის, მაგრამ ხანდახან ბოლომდე გაგება იმისა თუ რას საქმიანობს საერთოდ მოწყობილობა - რაც მთავარი პრინციპია დაბალი-დონის ინტერფეისებისა - მნიშვნელოვან როლს თამაშობს ზოგად პერფორმანსში (ჩვენ რომ 200 კადრი გვინდა წამში ის).

 

თუ ასე ტკბილია მაღალი-დონე, რა გვესაქმება დაბალი-დონის ინტერფეისებთან?

დაბალი-დონის ინტერფეისი დიდი ცვლილებაა 3D პროგრამირებაში, მათი დანერგვა მოითხოვს ინჟინრულ ძალისხმევას, ნაწილი პლატფორმის პროვაიდერებისგან, ნაწილი მოწყობილობების გამყიდველებისგან, ისევე როგორც თამაშის დეველოპერებისგან. უკანასკნელ ორ დეკადას რომ გადავხედოთ, მაღალი-დონის ინტერფეისები სრულებით საკმარისი იყო ჩვენთვის დამაკმაყოფილებელი 3D რენდერისთვის. თუ ასეა, რატომ მოგვინდა ახლა ამის შეცვლა? - არსებობს სხვადასხვა მიზეზები, ალბათ უფრო ის, რომ განვითარებაა საჭირო და არა ერთი ადგილის ტკეპნა. იმაზე აღარ ვფიქრობთ, თუ რაოდენ რთულია ახალი იდეის იმპლემენტაცია, რადგან ჩვენი მოთხოვნილება უფრო დიდია დღეს, ვიდრე სიზარმაცე. რაც უფრო მოწყობილობის მხარეზე გადავიხრებით, მით უფრო რთულია პრობლემის გადაჭრა, ამიტომაცაა ყველა დეველოპერი რომ გეტყვით, ოღონდ დრაივერს ნუ მაწერინებო (რაც ყველაზე ახლოა hardware-თან).

 

The Hardware Side

პირველადი დრაივერის დაწერა (ახალ გამომცხვარი), რა თქმა უნდა, GPU-სა და CPU-ს რესურსების კარგ ცოდნას მოითხოვს. დრაივერი მშობელს ჰგავს, რომელიც შვილს ლაპარაკს ასწავლის და ეს გამოთქმა ჩემი მოგონილი არ არის. ის ყველაზე კარგად აღწერს ამ ორის ურთიერთობას. ალბათ ინტუიცია დაგჭირდებოდათ, რომ გეფიქრათ, რაოდენ ძლიერ მიწისძვრას ჰგავს ცენტრალური პროცესორების ზოგადი განვითარება უკვე დანერგილი გრაფიკული ინტერფეისებისთვის, მაგრამ ის ფაქტი, რომ ეს ინტერფეისები არის ხიდი CPU-სა და GPU-ს რენდერინგის სიმძლავრეს შორის, სიურპრიზი ნამდვილად არ არის. სწორედ ამიტომაა, რომ კარგი API კარგ ოპტიმიზაციასაც მოასწავებს.

ადრეც აღვნიშნეთ, რომ მაღალი-დონის ინტერფეისები საკმარისად კარგი იყვნენ 90 წლიანების შემდგომი ორი დეკადის მანძილზე. ზემოთ ნაჩვენები გრაფიკი გვიჩვენებს high-end desktop პროცესორების მცურავ-მძიმიან პერფორმანსს და აქვე უნდა გაგჩენოდათ კითხვა - თუ ასე წრფივი იყო პროცესორის განვითარების მაჩვენებელი 90-იან წლებში, რატომ არ გამოიყენეს ეს დეველოპერებმა ბერკეტად და რატომ არ შექმნეს იმაზე კარგი, ვიდრე ჰქონდათ... როდესაც ვსაუბრობთ იმაზე, რომ თამაშები პროცესორის ყველა ბირთვსა თუ ნაკადს თანაბრად არ იყენებს, შეგვიძლია ეს გრაფიკი გაგვახსენდეს, რადგან მარჯვენა ფოტოზე კარგად ჩანს, თუ როგორც შესუსტდა ამ მოწყობილობების გამოთვლითი სიჩქარე, როდესაც ბირთვები ერთდროულად იტვირთებიან.

პროცესორზე საუბრისას არ უნდა დაგვავიწყდეს ვიდეო დაფებიც. 90-იანი წლიანების ადაპტერები დღევანდელისაგან რადიკალურად განსხვავდებიან. ისინი საკმაოდ დიდი ზომის მონაცემებს ამუშავებენ, ქმნიან გეომეტრიულ ნახაზებს საკუთარი ინიციატივით, როდესაც შეიძლებოდა უბრალოდ იმ დავალებაზე გაერთვა თავი, რასაც მოსთხოვდით.

მე თუ მკითხავთ ზედა ორი სტრიქონი საკმაოდ მოსაბეზრებელი იყო წასაკითხად და ერთი შეხედვით აბდა-უბდაც, მაგრამ ვინც კითხვას აგრძელებთ, ამ წინადადების ბოლოში მიხვდებით, რის თქმასაც ვცდილობდი, მოწყობილობების განვითარების გრაფიკი ისეთივე აბდა-უბდა იყო ბოლო წლების მანძილზე, როგორიც წინა ორი სტრიქონი და როგორც ვახსენეთ, ეს ინტერფეისების წისქვილზე წყალს ნამდვილად არ ასხამდა.

 

The Software Side

იმის გათვალისწინებით, რომ hardware-side განტოლების საკამათოდ მნიშვნელოვანი ერთი-ერთი ნაწილია და ყველაზე გამოქვეყნებადიც, software-side ცივი წყალივით იქნება ცხელ ზაფხულში იმ არსებული ინტერფეისებისთვის, რომლებსაც დღეს ვიცნობთ. ამის მიზეზი კი ისაა, რომ API არაფერია თუ არა software. ყველა გეიმერისთვის ნაცნობი უნდა იყოს შემდეგი სიტყვები: აი მეგობრები, იცით დღეს ჩვენ გამოვუშვებთ უმაღლესი დონის, ახალ თამაშს, დარჩით ჩვენთან და არ მოიწყენთ! - რამდენიმე წუთში კი ვიდეო დაფების მოვაჭრეები (NVIDIA, AMD) გამოაცხობენ ხოლმე ახალ „ოპტიმიზირებულ“ სათაურს: New Optimized Driver for full support of new features in game! არ იფიქროთ, ამ სარკასტულ სიტყვებს იმისათვის ვიყენებ, რომ დეველოპერები ან დრაივერის ინჟინრები დავაკნინო, მათი შეუთანხმებელი მუშაობის გამო. პირიქით, მათ მადლობაც უნდა გადავუხადოთ იმ ლამაზი გრაფიკის თამაშებისთვის, რაც დღეს გვაქვს. ეს სილამაზე რომ თქვენამდე მოვიდეს აწ მყოფი high-level ინტერფეისი კიდევ ერთხელ უნდა გაადნონ, უკეთ გამოაწრთონ და თამაშს მოარგონ. ამას იმისათვის აკეთებენ, რომ იმ ძრავამ საკუთარი თავი ბოლომდე გამოწუროს, რომელიც თამაშს გაუშვებს. ამ ყველაფრით დაღლილებმა, გადაწყვიტეს ახლის შექმნა და აი DX 12-ც. უკლებლივ ყველა დეველოპერი გეტყვით, რომ DX 11-სგან განსხვავებით, დრაივერები, რომელზედაც DX 12 მუშაობს უფრო მარტივად მისადგომია.

კარგად დააკვირდით ფოტოს. როგორც ხედავთ დრაივერის წილი ზოგად სურათზე დიდია. ეს ვიდეო ბარათების მწარმოებლებს სულაც არ აწყობთ, რადგან დეველოპერებს უჭირთ ბაგების დიაგნოზი და პრობლემის საკუთარი სახსრებით გადაწყვეტა, რის გამოც საჭიროა ამ ორი მხარის ერთობლივი მუშაობა. Game Code-ის სწორად აწყობა მარტივია, რადგან არსებობს ხელსაწყოები, რომლებიც პროგრამერებს საქმეს უადვილებს და დებაგინგში ეხმარება, მაგრამ... მხოლოდ hardware-ის გამყიდველს შეუძლია API-ს კედლის უკან გახედვა და დრაივერში კირკიტი.

თუ დრაივერი გადაწყვეტს, რომ ყოველი ფიგურის დაბეჭდვას დიდი დრო დაახარჯოს და ეს ყოველ წამში განმეორდა, თითქმის შეუძლებელი გახდება ინჟინრისთვის გაიგოს, რომელი Game Code-ს ნაწილია ამ არეულობაში პასუხისმგებელი, რაც თავის მხრივ დეველოპერის საქმეა და არა მაგალითად NVIDIA-სი და AMD-ს. თუ ფილმი იმ სცენარით წავა, როგორიც ფოტოზეა მოცემული, მაშინ თამაშების შემქმნელებს კიდევ უფრო მეტი შესაძლებლობა ექნებათ უფრო ლამაზი სურათების შექმნისა.

თანამედროვე თამაშების ევოლუციის ეკოსისტემა

რა თქმა უნდა, დრაივერსა და API-ზე დაზოგილი ენერგია შემდგომში თამაშების კოდზე აისახება და ძალისხმევა მის უკეთესად განვითარებისკენ იქნება მიმართული. ფაქტიურად, რომ დავუფიქრდეთ, მაღალი-დონის ინტერფეისები შესაძლოა პროგრამერებისთვის ფარივით იყოს, რაც თავის გამართლების საშუალებას აძლევს მათ. რომ იტყვიან, ბლაგვი ცულით ხის მოჭრა რთულია. ამის მიუხედავად, თანამედროვე თამაშები დაბალი-დონის ინტერფეისის წისქვილზე ასხამს წყალს და აქ ცოტა ჩაღრმავებაც საჭიროა.

90-იანი და ადრეული 00-იანი წლებისაგან განსხვავებით, დღევანდელ დროში უკვე იშვიათია, რომ თამაში ერთ, მზა, გამზადებულ ინტერფეისზე იქნას დაფუძნებული. ბევრ მსხვილ კომპანიას, გამომცემელს ყავს გუნდი, რომელიც დაკომპლექტებულია გამოცდილი დეველოპერებით, რომლებიც ყოველთვის ახალ-ახალ სიახლეს ნერგავენ საკუთარ ძრავაში. ეს არაფერია თუ არა წვალება. სწორედ ამიტომ, დაბალი-დონის API-ს განვითარება იმიტომაც იქნება კარგი, რომ საშუალო დონის დეველოპერს, რომელსაც რაღაც რესურსი და გამოცდილება აქვს, შეეძლება ხელის განძრევა - იმის მაგივრად, რომ პირდაპირ ზედა კლასს მიუკაკუნოს კარზე.

 

როგორ მუშაობს დაბალი-დონის API?

ნათელია, არსებობს სტიმული, როგორც hardware ასევე software-ს მხრიდან, რომ დაიწყონ დაბალი-დონის ინტერფეისის ახალი ფურცლიდან წერა, რის საშუალებასაც დღევანდელი ძრავების ეკოსისტემა იძლევა. მაგრამ მაინც რა არის low-level? სინამდვილეში DirectX 12 დიდი ცვლილებების მომასწავლებელია, მაგრამ განვიხილოთ ის ძირითადი საკითხები, რომელშიც წინსვლა უნდა გვქონდეს:

·         ზუსტად მოთხოვნილი დავალების შესრულება და არაფერი ზედმეტი

·         რენდერის მდგომარეობის მართვა

·         მეხსიერებისა და სხვა რესურსების ასინქრონული მართვა

 

1.       ზუსტად მოთხოვნილი დავალების შესრულება და არაფერი ზედმეტი

უმთავრესი მიზანი გრაფიკული ინტერფეისებისა არის ის, რომ ვიდეო დაფა ზუსტად მიყვებოდეს ინსტრუქციების კრებულს. მაღალი-დონის API-ში ეს უფრო აბსტრაქტული საქმეა, ვიდრე DX 12-ში, რომელსაც პირდაპირ შეუძლია ამ ყველაფერზე გავლენის მოხდენა. ფოტოზე ასახულია თუ როგორ მოქმედებენ ძველი და ახალი ინტერფეისები.

ძველ, კარგ დროში სიხშირეების გაზრდა საერთო სურათზე კარგად მუშაობდა, რასაც Direct3D 9 გვთავაზობდა, იყო ცხადი: აპლიკაცია იყენებდა ერთ კონტექსტს, სადაც მოთხოვნა მზადდებოდა, შემდეგ ეს მოთხოვნა მოწმდებოდა და ბოლოს GPU-ს ეგზავნებოდა შესასრულებლად.

 

DX 11-ში ფოტოზეც კი ჩანს განსხვავება. კონტექსტი, სადაც მოთხოვნა მზადდებოდა, იყო რამდენიმე ნაწილად დაყოფილი, რაც საშუალებას იძლეოდა დავალების სხვადასხვა ნაკადებში გადანაწილებას. ამის მიუხედავად, დასამუშავებელი მოთხოვნა შემოწმებას საბოლოოდ ერთ ბლოკში გადიოდა, რაშიც დრო იკარგებოდა, მაგრამ სამაგიეროდ შეცდომების რაოდენობა შემცირდა.

აი Direct3D 12-ს რაც შეეხება, თამაშის კოდს პირდაპირ შეუძლია მოთხოვნების შექმნა, ამავე დროს ის აკონტროლებს მზად არის თუ არა მოთხოვნა გადასაგზავნად რათა შესრულდეს და მას შემდეგ მიემგზავრება GPU-სკენ. მარტივად რომ ვთქვათ, შუამავლის თამაშიდან გასვლამ გამოიწვია ის, რომ ინტერფეისი low-level გახდა, რადგან დეველოპერს პირდაპირი წვდომა აქვს hardware-თან. ეს კარგია, თუმცა მან სიფრთხილე უნდა გამოიჩინოს რესურსების მოხმარებისას, როგორიცაა მაგალითად მეხსიერების ბუფერი, სადაც სურათები ინახება და სხვა მრავალი...

 

2.     რენდერის მდგომარეობის მართვა

რენდერი შეიცავს რამდენიმე ერთმანეთთან დაკავშირებულ ნაბიჯს, როგორიცაა პიქსელური ჩრდილების მომზადება ან/და რასტერიზაცია, რაც საბოლოოდ 3D სცენას ქმნის. ეს ეტაპი ერთ-ერთი უმნიშვნელოვანესია, რადგან პირდაპირპროპორციულად დაკავშირებულია საბოლოო სურათთან, რომელსაც ეკრანზე მივიღებთ, საუბარია იმაზე თუ რამდენ მსგავს ოპერაციას შეასრულებს ვიდეო დაფის პროცესორი.

უმეტესი ნაწილი მაღალი-დონის API-ებისა წარმოგვიდგენს აბსტრაქტულ წარმოდგენას ამ მდგომარეობაზე. მოცემული სურათი დაგვეხმარება მივხვდეთ თუ რაზეა საუბარი.

მოცემული საკმაოდ გამარტივებული ფიგურები, წარმოდგენას გვიქმნის საკითხზე. ვიდრე გამოსახულებას მივიღებდეთ, DX 11-ში მოთხოვნა მზადდება, შემდეგ დრაივერმა უნდა შექმნას ამ მოთხოვნის შესაბამისი თარგმანი hardware-სთვის, რათა მოწყობილობამ ასე ვთქვათ სურათი დახატოს. ამ პროცესში ის ასევე ამოწმებს ვალიდურია თუ არა მოთხოვნა და სიტყვაზე, ნამდვილად სამკუთხედს ვხაზავთ თუ მოხარშულ კარტოფილს, შემდეგ დავალება GPU-სთან მიდის და ისიც ასრულებს.

 

DX 12-ში დრაივერს მხოლოდ უკვე შექმნილი მოთხოვნის ვალიდურობის შემოწმებას ვთხოვთ, რის შემდეგაც GPU ეგრევე საქმეზე გადადის. კიდევ ერთი ხაზგასასმელი ფაქტი ისაა, რომ უკვე შექმნილი მოთხოვნა ვიცით რა ზომისაა, რაც შესაბამის მეხსიერების მისამართზე გაგზავნას იწვევს, ასე ვიგებთ დროსაც.

 

3.       მეხსიერებისა და სხვა რესურსების ასინქრონული მართვა

DX 12 დეველოპერებს საშუალებას მისცემს პირდაპირ მართონ მეხსიერება. თუ მაღალი-დონის API მათ სთავაზობს მოსახერხებელ ტექსტურებს, სამაგიეროდ წინ ეღობება GPU-სთვის ნაცნობ ბრძანებების ჩამონათვალსა და მონაცემების საცავებთან წვდომისას. ეს ყველაფერი DX 12-ში ხელმისაწვდომია.

კარგი ისაა, რომ დეველოპერმა იცის სად ინახება მისთვის საჭირო მასალა მეხსიერებაში, როდესაც მასთან წვდომას გადაწყვეტს. ასინქრონულ მუშაობს რაც შეეხება, ეს არის პროცესი, როდესაც GPU და CPU ერთმანეთის დამოუკიდებლად მოქმედებენ, მაგრამ პოტენციური პრობლემები მაშინ წარმოიშვება, როდესაც დრაივერი ვერ ახდენს მოთხოვნის ვალიდაციას (მოხარშულ კარტოფილზე რომ ვსაუბრობდით ხომ გახსოვთ). საბედნიეროდ ეს ეხება მხოლოდ high-level API-ს.

სურათზე იდეალურად არის წარმოჩენილი ის თუ რას ნიშნავს მოხარშული კარტოფილის დახაზვა. რა თქმა უნდა, ეს შეცდომაა და დეველოპერები ზუსტად იმაზე მუშაობენ, რომ ეს DX 12-ში არ მოხდეს. მოკლედ აქ რა ხდება: პროცესორი მოთხოვნილი X ნახაზის შექმნას ახმარს რესურს A-სა და B-ს, მაგრამ ცუდი ისაა, რომ სახეცვლილ რესურს B-ს მეორეთაც აკითხავს იმის გამო, რომ ვიდეო დაფა X ნახაზის შექმნას იგვიანებს. GPU მას შემდეგ იწყებს მოთხოვნის შესრულებას, რაც CPU-მ ორივე რესურსი გამოიყენა დავალების შესასრულებლად და ამავე დროს რესურსი B-ც შეიცვალა.

 შევაჯამოთ

ამ ყველაფერზე თავს ტყუილად არ აიტკივებდნენ. ეს იმისთვის კეთდება, რათა განვვითარდეთ და უკეთესი თამაშები შეიქმნას. ამას სჭირდება უკეთესი API-ს დანერგვა და ამაზე დიდხანს მუშაობა.

აპლიკაციის-დონის კონტროლი და ბრძანებების ჩამონათვალის (command lists) შეკრება საშუალებას იძლევა კარგად ბალანსირებული პარალელური მუშაობა შესრულდეს, რაც პროცესორის უტილიტიზაციასა და მისი ყველა ბირთვის კარგად გამოყენებას ნიშნავს. კომპიუტერის საერთო შესაძლებლობის ბოლომდე გამოსაყენებლად საჭიროა ზემოთ ახსნილი მუშაობის ზედმიწევნით სწორად შესრულება, რომ შედეგად არ მივიღოთ მოხარშული კარტოფილი. ეს ასევე დაზოგავს ცენტრალური პროცესორის დატვირთვას და ამავე დროს გაზრდის კადრების რაოდენობას. რესურსების ხელით მართვა დეველოპერებს საშუალებას მისცემს ზუსტად იცოდნენ სასურველი მონაცემი რა დროს სად იმყოფება. ეს მათ მუშაობასაც გაუადვილებს და ბაზრის საერთო სურათს გააუმჯობესებს.

 

რას ნიშნავს ეს გეიმერებისთვის?

ზემოთ ახსნილი დეტალები, თუ ამას დეტალები ჰქვია, ალბათ კარგად დაგანახებთ იმას, თუ რაოდენ დიდია რესურსების უაზრო ფლანგვა ამ მაღალი-დონის ინტერფეისებზე. DirectX 12 და მსგავსი დაბალი-დონის API უნდა გახდეს სასიცოცხლო მნიშვნელობის. ისინი კომპიუტერის პერფორმანსსაც გაზრდიან და თამაშის ხარისხსაც. ცუდი ისაა, რომ ეს შეიძლება ბევრმა თქვენთაგანმა ვერც კი შეამჩნიოს, რადგან ვიზუალურად DX 11-ც კარგად გამოიყურებოდა. კარგი ისაა, რომ მოთხოვნა დიდია, ყოველი თქვენთაგანი უფრო და უფრო რეალურ სცენებს ითხოვს, ამას კი მუშაობა სჭირდება და ეს მუშაობა უკვე დაწყებულია.

ყველაზე მნიშვნელოვანი წინსვლა და მატება იქნება ცენტრალურ პროცესორთან მიმართებაში, რაც გამოიხატება დატვირთვის თანაბრად გადანაწილებაში და პარალელიზმში. FPS-ის მატებას ნუ ელოდებით ისეთ სიტუაციებში, სადაც თქვენი high-end პროცესორი არ იყო დალიმიტებული. ასეთ შემთხვევებში განსხვავება მხოლოდ ენერგიის ეფექტურად მოხმარებასა და შემცირებულ „CPU usage“-ში იქნება. რაც შეეხება, მეტად რეალური სცენების შექმნას, ეს უკვე სხვა საქმეა, თანაც მომავლის.

ნუ იფიქრებთ, რომ თქვენ ბენეფიტებს ვერ მიიღებთ. ისეთ თამაშებში, რომელთაც Open-World-ს ვეძახით, მატება საგრძნობი იქნება. იქ სადაც სცენებში ბევრი მოძრავი ობიექტია, ცენტრალური პროცესორი ბევრ გამოთვლებს ახორციელებს. შესაბამისად ლოგიკურიცაა, რომ ამ შემთხვევაში მატება იქნება.

DirectX 12 ვინდოუს 10-ზე ნამდვილად წინ გადადგმული ნაბიჯია, მაგრამ მხოლოდ იმ შემთხვევაში თუ ამას მომავალში განვითარება მოჰყვება. უნდა შევეხოთ Vulkan API-საც, რომელიც OpenGL-ის მემკვიდრეა, ის და სხვა მსგავსი low-level ინტერფეისები მომავალში საშუალებას მოგვცემს რესურსები უკეთ გამოვიყენოთ, რაც ყველაზე მნიშვნელოვანია კიდე ისაა, რომ უფრო მეტ რეალურ გამოსახულებას მივიღებთ, უფრო მეტ რეალურ სცენებს და შევთანხმდეთ, რომ თამაში მხოლოდ FPS არ არის.

მადლობა ყურადღებისთვის. თუ რაიმე შეცდომაა და შესწორებას საჭიროებს, უმეთვალყურეოდ ნუ დატოვებთ. იმედია საინტერესო იყო.

[Barca]

მადლობა, ძალიან კარგი და საინტერესო სტატიაა, FB-ზეც გავიტანე ჩვენს გვერდზე.

[Power_VANO]

ძალიან კარგი სტატიაა! დიდი მადლობა!

[OpTiMeR]

არაფერს ბიჭებო, გაიხარეთ. ეს სტატია უნდა გვქონოდა, მრავალჯერ გარჩეულა აქ ეს თემა, ინტერესიც იყო და ახლა ცოტა ვრცლად შევეხე...

[George]

ამ ეტაპზე ძალიან ბევრი რამე რაც ფურცელზე უწერიათ dx12 სპეციფიკაციში ფურცელზევე რჩება, იმედია მართლა დაიხვეწება ნელ-ნელა, თან dx13 შეიძლება წლები არ გამოჩნდეს კიდე და საკმარისი დრო აქვთ მაგ აპის დახვეწვის, მე პირადათ მაგის იმედი უფრო მაქვს ვიდრე openGL შემცვლელი VulkanAPI რომელიც კიდე უფრო ნელი ტემპებით ვნითარდება და თამაშების საპორტიც საკმაოთ მცირეა ამ ეტაპზე

[ottko]

On 8/22/2017 at 3:23 PM, George said:

ამ ეტაპზე ძალიან ბევრი რამე რაც ფურცელზე უწერიათ dx12 სპეციფიკაციში ფურცელზევე რჩება, იმედია მართლა დაიხვეწება ნელ-ნელა, თან dx13 შეიძლება წლები არ გამოჩნდეს კიდე და საკმარისი დრო აქვთ მაგ აპის დახვეწვის, მე პირადათ მაგის იმედი უფრო მაქვს ვიდრე openGL შემცვლელი VulkanAPI რომელიც კიდე უფრო ნელი ტემპებით ვნითარდება და თამაშების საპორტიც საკმაოთ მცირეა ამ ეტაპზე

სამაგიეროდ dx12 ზე საკმაოდ მეტი წარმადობა აქვს  

 

[George]

აზრი თუ არ განვითარდა, DX12 ბევრი საინტერესო ფიშკაა ჩამოწერილი რომლებსაც ჯერ არც იყენებენ დეველოპერები, ეხლა ჯერ კიდევ ბევრი თამაში DX11 აპიზე გამოდის, ანუ მთლიანათ DX12-ზე ჯერაც არ გადასულან