Microsoft přidává podporu D3D12 Compute do Mesa 22.0

Doplnění - tady je web benchmarku, co jsem dělal s bráchou:
http://swarm.cz/gpubench/

Výsledky jsou v odkazu RESULTS. Je tam i srovnání softwarových rendererů Microsoft/SGI/Mesa:

Software (Mesa, P-MMX 133MHz)
Software (SGI, 486DX4 75MHz)
Software (SGI, P-MMX 133MHz)
Software (WinNT4, P-MMX 133MHz)
Software (WinNT4, 2xP3 1GHz)

Doplnění od bráchy:

Microsoft OpenGL neupradoval na MMX, protože v té době už byl rozkaz focusovat se na Direct3D. Nicméně zk*iplené nebylo... jen prostě vyšlo v době před MMX. To OpenGL od SGI pro Windows, které MMX mělo, vyšlo o nějaké roky později. Kdyby byla ještě původní vůle prosazovat OpenGL ve Windows, věřím, že by tam MMX přidali stejně jako třeba i nějaké další extense.

Ale v době, kdy to OpenGL od MS vyšlo, tak bylo za mě naopak dost dobrý. Však netexturovaný věci se s ním daly používat i na rychlejších 486. U komerčních UNIXů si kolikrát za podporu OpenGL platit extra licence. Mám pocit, že po IRIXu byl Windows NT prvním OS, kde jsi mohl bez poplatků, out-of-the-box začít psát OpenGL programy.

Takhle to ale není. Fractional scaling fungoval v dobách, kdy Wayland ještě neexistoval. Tak jako se okamžitě překreslily aplikace v GTK a Qt, když jsi v nastavení změnil DPI, tak pro multimonitor se tenhle event posílal aplikacím po přetažení na druhý monitor. A nemáte ani pravdu v tom, že se na podpoře High DPI nepracuje pro XWayland - první verze (nejprve natvrdo pro konkrétní aplikaci) už funguje na Fedoře pro Chrome (ten tam zatím, nebo aspoň nedávno, běžel přes XWayland). Funguje včetně přetažení na monitor s jiným DPI (akorát kuzor myši je pak blbě - podle toho se to pozná).

Akurat to nebol fractional scaling, ale specifikacia DPI pre displej (nie screen!). Bolo mozne mat viacero screenov s rovnakym dpi v ramci jedneho displeja, alebo viacero displejov s jednym screenom, ale v druhom pripade nebolo mozne presuvat okna z jedneho na druhy - aplikacia musela na jednom displeji okno zrusit a na druhom vytvorit. Toto zvladal akurat XEmacs, nic ine. Co sa tyka samotneho dpi, aplikacie nacitali globalne nastavenie pri starte, pouzivali ho po zvysok session a skalovali iba velkost fontov, ale nie ostatnych assetov, obzvlast nie rastrovych. Vyzeralo to dost zle a presne toto hidpi riesi.

No a ze sa pracuje na whiteliste pre specificke aplikacie? Zabity cas, riesenie pre jednu aplikaciu, ale ked to niekoho bavi, nech sa hra. Google mohol radsej zapracovat na podpore Waylandu v Chrome... Ostatne stare X11 aplikacie s tym fungovat aj tak nebudu, z dovodu, ktory som spomenul vyssie.

Vo Windows situacia je podobna - 99% aplikacii pri pouziti s large fonts (co je ekvivalent X11 dpi) je rozbitych. Preto Windows 8/10 prisli s novymi API pre hidpi.

MacOS zase pre zmenu povie vsetkym aplikaciam ze bezia v hidpi (ak je aspon jeden pripojeny displej hidpi) a skaluje to smerom dole v displej serveri. Vysledky to dava vacsinou uspokojive, okrem niektorych velkosti, ako napr. 125%. Preto tato velkost, popularna v PC svete (fullhd@14"), v MacOS nie je dostupna vobec.

1. DPI, které není násobek 100 %, je fractional scaling.

2. Nevím, co mícháte nějaké obrazovky a screeny. Mluvím o tom obdélníkovém zařízení zobrazujícího obraz. Desktopový monitor nebo displej notebooku.

3. Nemluvím o separátním X serveru na druhém monitoru. Mluvím o více monitorech obsluhovaných jedním grafickým serverem (můžete např přetahovat okna).

4. Nemáte pravdu. Čisté GTK a Qt aplikace škálovaly i rastrovou grafiku a projevila se změna DPI okamžitě. Jiné aplikace, jako např Firefox, bylo třeba restartovat (četly si DPI jen pro startu, ale škálovaly i rastrovou grafiku). Určitě byly aplikace, které škálovaly jen fonty, ale takové byly i např ve Windows. Příslušně upravit aplikaci bylo mnohem míň práce než ji předělávat na Wayland (to totiž není jen přechod na vyšší major verzi GUI toolkitu, ale i zbavení se všech volání X11 - přitom dodnes např GTK 3 neumí relative mouse movement, takže musíte psát vedle sebe příkazy X11+Wayland).

5. Zabitý čas to není, protože člověk není živ jen desktopem, terminálem, jednoduchým file manažerem, notepadem a webovým prohlížečem. Takový GIMP (jeden z nejvýznamnějších grafických software na Linuxu) začal přechod na GTK 3 až nedávno (čekal,naz se ustálí vývoj, který každou chvíli přinesl nějakou nekompatibilitu).

6. Google samozřejmě pracuje na podpoře Wayland v Chrome. Experimentálně to jde zapnout. Ale nezapomeňte, že na Waylandu se stále pracuje - ještě se dodělává poslední základní funkčnost. Některé aplikace na to musí počkat.

7. Není pravda, takzvané Large Fonts (DPI 125 %, mimochodem většina dnes prodaných notebooků - FullHD na 15") fungují ve Windows od verze 3.x - z dob kdy ještě žádný Linux neexistoval! Proto je jeho podpora i v 10, někdy i 20, let starých programech. Problém ve Windows nastal s DPI 150 % a vyššími. Nicméně Microsoft to zvládl udělat tak, že není třeba předělávat aplikaci na jiný grafický server, GUI framework, nebo aspoň vyšší major verzi stávajícího frameworku. Stačí přidat položku do manifestu, že aplikace umí HighDPI nebo MultiDPI a odpovídat na nové eventy. Mimochodem, starší aplikace, které umí jen HighDPI (jeden monitor, s vyšším DPI), ale ne MultiDPI (více monitorů, s různým DPI), fungují aspoň na primárním displeji (v XWayland by je rozmazal - dokud nebude pro tohle dokončena vámi zavrhovaná podpora v XWayland).

8. MacOS byl vždycky OS pro grafickou práci, takže přirozeně přinesl masivní nástup HighDPI. Váš vysmíváný systém škálování mimochodem používá i ten "úžasný" Wayland. Jenže Apple si to může dovolit, protože k tomu dodává dostatečně výkonné GPU. Mimochodem i 125 % brácha rozchodil na externím displeji k macbooku - je třeba ale použít hack s pomocným virtuálním monitorem.

1) Nie, nie je. Fraction == zlomok. 200% alebo 300% nie je fractional scaling, ale integer scaling.

2) Pokial neviete, zopakujte si terminologiu X11. https://en.wikipedia.org/wiki/X_Window_System#Key_terms

3) V tomto pripade v X11 obe musia mat rovnake DPI. V case ked sa to navrhovalo zjavne nepocitali s tym, ze kazdy screen moze mat inu hodnotu.

4) Nie, neskalovali. Okrem toho to nie je len na frameworku, ale aj na aplikacii. Ked GIMP zobrazuje nejaky subor, musi vediet, co urobi s ikonami v toolbare a co so samotnym pouzivatelskym suborom (doteraz to nevie). Detto Remmina.

5) GIMP konkretne ma problem s clovekohodinami -- resp. s tym, ze ich nikto nedava do tohto projektu. GTK3 je tu vyse 10 rokov.

6) Ked porovnam, ako rychlo boli schopni urobit niektore veci (napr. podpora ARM) a ako sa vlecie podpora Waylandu, tak Chrome pre Linux ma zhruba rovnaku prioritu ako ten GIMP ;). Ta "zakladna" funkcnost ktora sa doraba su upravy, ktore mohli byt urobene len na zaklade skusenosti aplikacii z praxe... ktore na to tiez nejaku dekadu zvysoka. Zobudili sa, az ked RHEL dal Wayland ako default, ze aha, oni to fakt myslia vazne.

7) Linux v tej dobe existoval, bola to jedina moznost, ako mohol mat bezny student doma 32-bitovy system aj s X11. Large fonts bolo rozbite odkedy sa zacali objavovat aplikacie napisane v Delphi (t.j. tiez doba Windows 3.x), kde na to programatori tiez zvysoka, ved na ich pocitaci to islo dobre... A ako to viem? Mal som 17" monitor s rozlisenim 1280x1024, kde bolo treba pouzivat Large fonts, tak velmi dobre viem, co vsetko neslo.

> Nicméně Microsoft to zvládl udělat tak, že není třeba předělávat aplikaci na jiný grafický server, GUI framework, nebo aspoň vyšší major verzi stávajícího frameworku. Stačí přidat položku do manifestu, že aplikace umí HighDPI nebo MultiDPI a odpovídat na nové eventy

Microsoft ma ten "luxus" ze kazda jedna aplikacia ma dynamicky prilinkovane gdi.dll a tam si mozu poupravovat co chcu. Linuxovy displaj server musi fungovat s kazdou aplikaciou, ktora si otvori X11 socket a hovori X11 protokolom, ci uz je to historicky libx11 nalinkovany staticky, najnovsi libxcb, nalinkovany dynamicky alebo doma uvarena kniznica na X11 protokol (boli take pokusy v go...).

> Mimochodem, starší aplikace, které umí jen HighDPI (jeden monitor, s vyšším DPI), ale ne MultiDPI (více monitorů, s různým DPI), fungují aspoň na primárním displeji (v XWayland by je rozmazal - dokud nebude pro tohle dokončena vámi zavrhovaná podpora v XWayland).

Ono je dost aplikacii, ktore su rozmazane aj vo Windows.

8) Ja sa downscalingu nevysmievam, kde ste to nasli? Ono to ma dovod, preco to Apple zatrhol - treba zobrazovat 8 logickych pixelov pomocou 5 fyzickych, a ono to fakt uz vyzera dost blbo. Apple ani take displeje nema, ktore by to potrebovali. Na Linuxe alebo Windowse bohuzial pouzivatelom povedat nemozete, pocuvat nebudu a budu si dupat svoje, a potom sa stazovat, ze to blbo vyzera - aj ked presne to je dovod, preco to nebolo podporovane v prvom rade.

1. Však to jsem psal: "DPI, které není násobek 100 %, je fractional scaling."

2. Vy jste začal se slovíčkařením, co jednotlivé termíny znamenají v jednom z mnoha grafických API, o kterých se bavíme. Já předpokládal, že každý chápe pod obrazovkou/scre­enem/monitorem to samé.

3. Je pravda, že X11 podporu monitorů s různým DPI sám neřeší, ale řešilo to desktopové prostředí. Koneckonců ani Wayland mnoho věcí neřeší a zůstává to na desktopovém prostředí (duplicitní práce, jak každé to musí implementovat znovu - uvidíme, jestli vzniknou nějaká DE např. na wlroots, který se to snaží sjednotit). Nejpoužívanější distribucí bylo Ubuntu, a v něm jeho prostředí Unity to umělo - postupem, jak jsem popisoval. Poslal event o změně DPI oknu po přesunu na druhý monitor s jiným DPI. Vzhledem k enormní roztříštěnosti linuxových distribucí samozřejmě věřím, že byly i takové, kde to nefungovalo (koneckonců ani ten Wayland dodnes ani po 10 letech ve většině distribucí nefunguje!).

4. Jak píšu, moje zkušenost je, že aplikace neměly problém škálovat i ikony např. v toolbaru. Měnil jste skutečně DPI, nebo jen velikost písem?

5. První roky ale bylo GTK 3 každou chvíli rozbité. Navíc pokud má GIMP problém s člověkohodinami, co většina toho software, co dělají fanoušci opensource o volném čase po práci?

6. Chrome podporoval ARM už z dob prvních chromebooků a co byl naportován na Android (nejprv tam byl jiný prohlížeč). Myslím, že v současnosti v Chrome na Wayland nefungují jen věci, které ještě nejsou ve Wayland hotové - až budou, tak to Google implementuje.

7. Já Delphi taky používal, ale 125 % DPI monitor jsem tehdy neměl, tak nevím. Jinak je třeba rozlišovat mezi původním režimem 125 % "Large Fonts" a tím moderním roztahováním ve Windows, které rozmaže i tyto aplikace a neptá se, jestli umí 125 %. Pokud máte displej s DPI 125 %, tak na původní systém (ostrá grafika) jde stále přepnout, akorát ve Windows 11 už jen v registru. Windows to takhle dělá, aby fungovalo případné připojení externího monitoru s jiným DPI. Ale není to problém, díky mnohem jednodušší implementaci High/MultiDPI ve Windows aplikacích se podpora rychle přidala do většiny z nich.

Kolik aplikací mluví s X serverem přes socket? Většina přes knihovnu. Resp. přes nějaký GUI toolkit nad tím. Nikdo neříká, že 100 % aplikací musí být dokonalé (tj. ne roztažené s rozmazáním - to ale stačí jako fallback). Stačí podpora pro aplikace GTK/Qt/SDL nebo "přímo" přes X11 knihovnu a pokryjete tím většinu aplikací a her. Když jsem studoval zdrojáky Quake 1 (použil jsem je pro X11 verzi benchmarku GPUbench, viz https://www.root.cz/zpravicky/microsoft-pridava-podporu-d3d12-compute-do-mesa-22-0/#o1084911 ), tak i tahle stařičká hra kreslila přes X11 knihovnu a ne socket.

>> Mimochodem, starší aplikace, ...
>Ono je dost aplikacii, ktore su rozmazane aj vo Windows.
Situace, o které jsem mluvil, je cca 10 let stará aplikace (tj. ještě před zrozením Waylandu), která podporuje vyšší DPI, ale ne různé monitory s různým DPI. Windows ji vykreslí v DPI primárního monitoru - na ostatních monitorech ji škáluje jako bitmapu, ale tu highres verzi podle primárního monitoru, ne podle DPI 100 %. V XWayland to ignoruje a bere ji jako aplikaci, co nic o DPI neví. Samozřejmě pracuje se na tom, aby to fungovalo - navzdory vašim nářkům.

8. Apple to potřebuje, protože víceméně neprodává externí monitory - uživatel musí připojit "PC" monitor. PC je o velkém rozmezí výkonu a ceny, a proto Windows zvolil nativní vykreslování pro různá DPI. Tj. pro dnes nejrozšířenější DPI 125 % není třeba 2,56x výkonnější GPU pro kreslení DPI 200 % (a pak downsamplovat). Wayland šel cestou Apple, takže Linux je na stejném HW pomalejší než Windows.

Nefungoval vždy to DPI bylo stejné měl jsem 4K a FullHD a hrál jsem si s tím fakt dlouho a na X11 to prostě nejde aby měla jedna obrazovka jiné DPI jako druhá.

Nevím, jak rozšířenost linuxového desktopu rozbije jeho aktualizace? Linux je bez nadsázky nejrozšířenější uživatelský operační systém v celé sluneční soustavě a desktop pouhá podmnožina aplikací, které můžeš nebo nemusíš mít (narozdíl od Windows ne-server).

Aktualizací jednotlivé distribuce připravují dohromady stovky, možná i tisíce, denně. A nevím o případu kdy aktualizace jako taková zlikvidovala uživatelská data. Vím o znepřístupnění vlivem chyby aplikace, vím o poškození vlivem chyby admina (ať už aktualizací nebo přeinstalací systému či aplikace), ale ne o masivním mazání, protože aktualizace.

P.S. Ve Windows oddělení v bývalé práci měli pěkný bobky z každé aktualizace a divil by ses kolik jim dalo práce, než je pustili na všechny stanice. A to byly všechny centrálně spravované a uživatelé neměli admin práva.

Asi mám dnes pomalejší vedení, ale můžeš mi prosím lépe vysvětlit jak dnes aktualizace rozbíjí linuxový desktop?

No popravdě řečeno už hodně (opravdu hodně) dlouho ne. A to tak, že si nepamatuji vážnější problém. A pokud bych to vztáhl na jádro, základní OS a desktop, tak od okamžiku, kdy nepoužívám nvidia GK, tak snad vůbec.

A pokud to vezmu obecně, tak zde, prosím, srovnáváme nesrovnatelné - v Linuxu je téměř vše volitelná aplikace - můžu ji mít nebo nemusím. Vše se navíc řídí centrálním repozitářem distribuce, takže se stírají rozdíly mezi „základním systémem“ (jádro + desktop) a „aplikací třetích stran“ (např. grafický/texto­vý/video editor, antivir, pracovní nástroje...) jako je to u Windows. A chyby v aplikacích jsou napříč operačními systémy a mohou rozbíjet něco co chvíli. U Win se kritika snese na autora, u Linuxu na distribuci, ale chyba je pořád u autora.

V každém případě, nezažil jsem, kdy by aktualizace způsobila smazání uživatelských dat. Mohou být nepřístupná, ale ne smazaná. Případně, ve verzi X něco jede, ve verzi x+1 už ne. Ale opět to jsou věci, co se dějí všude zhruba stejně. Ale stále mohu obvykle jít o krok zpět...

Ano, jak už tu bylo víckrát řečeno, některé problémy v (desktopovém) Linuxu "nenastávají" jednoduše díky jeho marginálnímu rozšíření. Však i ve Windows ty problémy byly u tak malého promile uživatelů, že to MS ignoroval. Problém byl právě v tom, že pro určité typy chyb (smazání dat) by neměla být žádná hranice, kdy problém ignorovat.