უკან დაბრუნება
Linux 7.3-ში ვიდეომეხსიერების ამოწურვისას წარმადობა გაუმჯობესდება
SiTech AI Team2 წთ. საკითხავი

Linux 7.3-ში ვიდეომეხსიერების ამოწურვისას წარმადობა გაუმჯობესდება

VRAM-ის მართვაზე მომუშავე ბირთვის პატჩები upstream-ში მიღებულია და Linux 7.3-ის რიგშია: ვიდეომეხსიერების ამოწურვისას თამაშები ნაკლებად ვარდება, წარმადობა კი უფრო სტაბილური ხდება.

ვიდეომეხსიერების (VRAM) მართვაზე მომუშავე ბირთვის პატჩები upstream-ში მიღებულია და Linux 7.3-ის რიგშია — ამის შესახებ ავტორი pixelcluster-ის GPU ბლოგზე 17 აგვისტოს გამოქვეყნებულ ჩანაწერში წერს. მანამდე ის იმავე თემაზე თამაშებისთვის VRAM-ის მართვის გაუმჯობესებაზე მუშაობდა და პოსტში ხსნის, თუ რა ხდება რეალურად, როცა თამაში ფიზიკურად არსებულ მეხსიერებაზე მეტს ითხოვს.

რას ნიშნავს VRAM-ის გადავსება

თეორიულად ვიდეომეხსიერების ამოწურვა მხოლოდ წარმადობის, და არა სტაბილურობის პრობლემა უნდა იყოს: დრაივერი ნებას გაძლევს მოითხოვო მეტი მეხსიერება, ვიდრე GPU-ზე ფიზიკურადაა, ნაწილი კი CPU-ის RAM-ში გადადის. სწორედ ეს გადატანა არის ბოთლის ყელი — PCIe 4.0 x16-ზე გამტარობა 32 GiB/წმ-ზე ოდნავ ნაკლებია, ანუ ~32.2 MiB მილიწამში. 30 კადრი/წმ-ისთვის ერთ კადრს 33.3 მწ ეძლევა, რაც იმას ნიშნავს, რომ კადრზე მაქსიმუმ ~1075.5 MiB მონაცემია წვდომადი. თუ GPU-ს ერთ კადრში 1 GiB-ზე მეტის წამოღება სჭირდება, 30 კადრი/წმ მიუღწევადია.

სტაბილურობის ხარვეზი: ჩიხი ბირთვის ჩაკეტვაში

პრაქტიკაში ამოწურვას თან სდევს შეცდომა radv/amdgpu: Not enough memory for command submission. გასაოცარი ისაა, რომ ყველა ალოკაცია წარმატებით დასრულდა — ბირთვი კი მაინც აბრუნებს -ENOMEM-ს. მიზეზი ABBA ტიპის ჩიხია: ერთი გაგზავნა ცდილობს გამოაძევოს ალოკაცია, რომელიც მეორემ უკვე ჩაკეტა, მეორეს კი პირველის ალოკაცია სჭირდება. ბირთვს ჩიხის აღმოჩენა და განმეორებითი ცდა drm_exec დამხმარე ბიბლიოთეკით შეუძლია, თუმცა TTM-ში — საერთო GPU მეხსიერების მართვის ფენაში — ის არ გამოიყენებოდა. ავტორმა 2024 წლიდან მოუწესრიგებელი პატჩები გადაიტანა და ბაგები გამოასწორა; ერთი კვირა დასჭირდა იმ შემთხვევების დაჭერას, როცა თამაშები VRAM-ის დაძაბვიდან სამი წუთის შემდეგ იკიდებოდა.

ეკრანის სკანირება და ფიზიკური უწყვეტობა

წარმადობის დიდი ნაწილი მეხსიერების გადაადგილებას (sdma0) ხმარდება და არა კადრის რენდერს. მიზეზი ეკრანზე გამოსატანი გამოსახულების ბუფერია: დისპლეის ტექნიკა ვირტუალურ მეხსიერებას გვერდს უვლის და ფიზიკურად უწყვეტ მისამართებს ითხოვს. გამოძევების ალგორითმი კი ფიზიკურ შეზღუდვებს არ ითვალისწინებს და LRU სიას მიჰყვება — შედეგად, R11G11B10 ფორმატის ~32 MiB-იანი სკანირების ბუფერისთვის ადგილის გასათავისუფლებლად ზოგჯერ 4 GiB-მდე VRAM-ის გამოძევება ხდება. მხოლოდ ამ მონაცემების გადატანა PCIe-ის ტემპით ~130 მწ-ს მაინც ჯდება. ამიტომ დაემატა ე.წ. მკაცრი და რბილი შემფარდების ფაზები, რომლებიც პროცესს რამდენიმე მილიწამიდან რამდენიმე წამამდე აჩერებს.

რას იძლევა პრაქტიკაში

ტესტში Indiana Jones: The Great Circle 8 GiB-იან სისტემაზე 9 GiB-ს ითხოვდა და კადრზე საშუალოდ 19.6 მწ აჩვენებდა — სავსებით სათამაშო. 10 GiB-ის მოთხოვნისას ვარიაცია იზრდება, ნახტომები 33.3 მწ-ს სცდება. ბირთვი ახლა პრიორიტეტებსაც ითვალისწინებს: VK_EXT_pageable_device_local_memory და vkSetDeviceMemoryPriorityEXT აპლიკაციას აძლევს საშუალებას, მიუთითოს, რომელი მეხსიერებაა გამოსაძევებლად უფრო უსაფრთხო.

SSiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.