Názory k článku
AMD otevírá oficiální ovladač pro Vulkan
-
Peter FodrekZlatý podporovatel"Vznikl, protože neexistoval oficiální otevřený multiplatformní ovladač přímo od AMD."
To nie je uplne pravda, RADV vznikol, kedze AMD trvalo otvorenie ovladaca prilis dlho
AMD povedalo uz 17.9.2015,ze bude mat v buducnosti open source Vulkan driver
AMD Has A Vulkan Linux Driver, But Will Be Closed-Source At First
Written by Michael Larabel in Display Drivers on 17 September 2015.This was the first time we've heard AMD's Linux team talk about Vulkan... They are working on a Vulkan Linux driver and have one prototyped, but initially it will be closed-source and the open-sourced later..
https://www.phoronix.com/scan.php?page=article&item=amd-gpu-xdc15&num=1 -
Přezdívka (neregistrovaný)
Ale trvalo jim to tak dlouho, že mezi tím 2 nadšenci ve volném čase zvládli napsat mnohem jednodušší a v dost věcech citelně výkonnější RADV...
-
Přezdívka (neregistrovaný)
Ještě k tomu si žádný jiný dostupný driver ani neškrtá vůči radeonsi Galliu.
-
Peter FodrekZlatý podporovatel
RadeonSI je openGL nie Vulkan ovladac, vyvijany dominantne zamestnancami AMD
A ano ten je rychlejsi aj oproti aktualnemu openGL ovladacu AMD. vid testy vyssie
A tento novy ovladac vie kombinovat openGL ovladac RadeonSI a Radeon Open Vulkan z AMDGPU-PRO, alebo openGL ovladac z AMDGPU-PRO a RADV, pripdane ostane dve moznosti, podla Vasej vole .
Coming out today is the AMDGPU-PRO 17.50 driver that bundles in the open-source RADV and RadeonSI drivers too, in letting you "mix and match" the driver components you want for your system.
https://www.phoronix.com/scan.php?page=article&item=amdgpu-mix-match&num=1Este, keby to tak islo switchovat on the fly
-
Přezdívka (neregistrovaný)
Já vim. Říkám, že aktuálně je otevřený OpenGL rychlejší než cokoliv jinýho (RADV, oficiální "Radeon Open Vulkan" i binární AMDGPU-PRO/Catalyst/fglrx OpenGL). Samozřejmě to klidně může být důsledek toho, jak špatně pasuje design původně OpenGL rendereru na Vulkan (ještě k tomu po tom, co už ho někdo napasovával z Direct3D na OpenGL).
Přepínat drivery jde pomocí env variables. -
Peter FodrekZlatý podporovatel
Vazne - staci zmenit env a jadro auromnatiocky prepne z RADV na Radeon Open Vulkan? To by bolo dobre
A s tymi renedermi, renderemi , mate na myslki to, ze L4D, mala v direct3D 270 fps, prostym preklopenim do openGL mala 6 fps, po opraveni chyb mali 315 fps v linuxe a 303 fps vo Windows s openGL renederom (DirectX s povodnymi chybami mal 270 fps)?
The presentation was made by Rich Geldreich of Valve and entitled "Left 4 Dead 2 Linux: From 6 to 300 FPS in OpenGL.
https://www.phoronix.com/scan.php?page=news_item&px=MTE1NzEUsing a NVIDIA GeForce GTX 680 graphics card with an Intel Core i7 3930K processor, Windows 7 SP1 was running Left 4 Dead 2 with the Direct3D renderer at 270 FPS while under Linux with OpenGL they are now at 315 FPS! Using the OpenGL renderer on Windows isn't also quite as good with its average frame-rate at around 303 FPS.
https://www.phoronix.com/scan.php?page=news_item&px=MTE1MjI -
Přezdívka (neregistrovaný)
Jádro (kernel) nic nepřepíná. Programy, co používají Vulkan, se linkujou na libvk loader od LunarG. Tomu se proměnnou VK_ICD_FILENAMES předá cesta k manifestu, kde je napsaný
{ "file_format_version": "1.0.0", "ICD": { "library_path": "path to ICD library", "api_version": "1.0.5" } }a to už ukazuje na konkrétní driver.
-
Peter FodrekZlatý podporovatel
vdaka, preco som si myslel, ze je to zmena v module a nie v user space casti.. Moja chyba
-
Peter FodrekZlatý podporovatel
Ja som vedel, že má byť jednotný kernel space, ale raz mi niekto povedal, že AMDGPU.ko má inú verziu v AMDGPU-PRO
-
Přezdívka (neregistrovaný)
A měl pravdu, protože -PRO s sebou táhne DKMS kompilovanou verzi amdgpu.ko, obsahující kód, co potřebuje jejich binární OpenGL a buď ho ještě nestihli upstreamovat nebo ho upstream nikdy nepřijme. Taky nějakou dobu neřešili, jestli bude s touhle verzí amdgpu fungovat radeonsi Gallium (natož RADV).
-
Peter FodrekZlatý podporovatel
Ale potom treba tie moduly bud vymenit, alebo tewn PRO uz vie fungovat s radeonsi a RADV, aspon v najnovsom PRO ovladaci
-
Přezdívka (neregistrovaný)
Pro OpenGL vyvíjí nVidia podobný ABI a už ho implementuje jejich proprietární blob i Mesa (od verze 17.1 po kompilaci s argumentem --enable-libglvnd), takže je možná bezkolizní instalace několika různých OpenGL driverů a přepínání mezi nimi (respektive dispatcher/loader přepíná driver podle výstupu, na kterej se vykresluje - renderování a zobrazování téhož snímku na různých GPU vyžaduje DRI_PRIME).
-
Přezdívka (neregistrovaný)
Na straně kernelu řídí HW modul amdgpu.ko a všechny OpenGL a Vulkan drivery používají jeho syscall rozhraní. ROCm OpenCL driver zase používá syscall rozhraní modulu amdkfd.ko.
Pokud jde o výkon, ne každý je pro něj ochotný udělat to, co VALVE - viz. třeba porty od Virtual Programming. -
Peter FodrekZlatý podporovatel
Kde v com, okrem Mad Maxa, je rychlejsi RADV oproti Radeon Open Vulkan (https://www.phoronix.com/scan.php?page=article&item=amd-open-vulkan&num=1)
https://www.phoronix.com/scan.php?page=article&item=amdgpu-1750-open&num=3
-
-
Přezdívka (neregistrovaný)
Asi jo, ale vzhledem k tomu, že na všechno ostatní maj veřejný GIT repozitáře, bych tady čekal víc, než jenom používanou modifikaci LLVM.
-
Přezdívka (neregistrovaný)
Dělal a je to tam úplně stejný - procesy na procesy. Akorát typická perioda vývoje produktu je cca. 3 roky, takže 2 roky na každou blbost by asi dost skřípalo. Výsledkem samozřejmě je, že se ty procesy každej snaží obcházet, kde jenom může, protože by jinak nikdy nic neudělal.
-
Přezdívka (neregistrovaný)
Právě že jak v čem - ve spoustě věcí je rychlejší už teď a jakmile konečně budou k dispozici zdrojáky oficiálního driveru, tak z nich půjdou vyzobat jakýkoliv optimalizace, co RADV zatim nedělá a podobně.
Navíc korporátní prostředí často generuje zbytečně složitý řešení, takže RADV může být přímočařejší (takže s omezenými prostředky dlouhodobě lépe udržitelná) implementace. Zároveň oficiální Vulkan driver sdílí kód s implementacemi dalších API na dalších platformách, takže sice těží z prostředků na nepostradatelný vývoj, ale současně ho zatěžuje zmíněná korporátní byrokracie - teoreticky může kdokoliv kdykoliv poslat patch, ale interní vývojáře to zatíží minimálně testováním, jestli nenadělal víc škody než užitku (hlavně v preferovaných žáležitostech), čemuž může minimálně management aktivně vzdorovat - a nikdo neví, jak bude takový model vývoje dlouhodobě fungovat.
Nakonec může být paralelní vývoj s částečnou duplikací aktivit a občasným přetahováním kódu jediná oboustranně schůdná možnost.
