Diit.cz - Novinky a informace o hardware, software a internetu

Diskuse k Grafika v procesorech Intel Ice Lake umí DisplayPort 1.3/1.4 [prezentace]

Chybka "5120×288@120 Hz "

+1
0
-1
Je komentář přínosný?

Definice bezeztratove komprese neni v clanku uvedena spravne. Bezeztratova komprese je takova komprese, pri niz nedochazi ke ztrate informace.

+1
-2
-1
Je komentář přínosný?

Doporučuji si to přečíst ještě jednou. Jde o vizuálně bezztrátovou kompresi a nikoli (datově) bezztrátovou kompresi. Komprimovat v reálném čase obraz datově bezztrátově v relativně vysokém a navíc stabilním kompresním poměru je z principu nemožné.

+1
+3
-1
Je komentář přínosný?

Vizualne bezstratova komprese je marketingovy krasozvast. Komprese je proste bud ztratova nebo bezstratova, nic mezi tim neni, stejne jako zena je bud tehotna nebo ne-tehotna, ale ne trosku tehotna, nebo vizualne tehotna, atp. . Pokud by jste si dali tu praci a vyhledali a prostudovali patricnou dokumentaci, tak zjistite ze i samotna VESA priznava, ze to s tou vizualni kvalitou komprimovane verze neni stoprocentni, nicmene dle jejich mineni je tam zanedbatelny rozdil (coz je ovsem dost individualni). Dalsi blbost je ta zminka o milisekundovych zpozdenich, pokud by autor nastudoval dokumentaci, tak by vedel, ze DSC komprimuje po radcich, a tudiz zpozdeni by nemelo byt delsi nez doba vykreslovani jednoho radku (coz jiz i v mizernem PALu bylo 64 mikrosekund). Je tomu tak proto aby vyrobci usetrili na hardware en/decoderu a potrebny buffer nemusel byt prilis veliky, cili nikdo soudny tam nebude pouzivat frame-buffer (nebo jiny velky buffer), ktery jediny by umoznil zpozdeni v radu desitek milisekund a pritom neni vubec nutny!

+1
+6
-1
Je komentář přínosný?

>vizualne tehotna

To si viem predstaviť v pojme vyzerá ako tehotná..

+1
+4
-1
Je komentář přínosný?

Ono to máš občas složitý. Pregnantní ilustraci (příklad) můžeš taky přeložit jako "těhotný obrázek" a pak nad tímto svým "překladem" začít filozofovat :)))

+1
0
-1
Je komentář přínosný?

1. Nejde o krasožvást, jde o definici toho, čeho se ona ztráta při kompresi týká, respektive netýká. Pokud mezi daty před kompresí a po (de)kompresi není rozdíl, je datově bezztrátová. Pokud mezi obrazem před a po (de)kompresi není vidět rozdíl, jde vizuálně bezztrátová.

2. „pokud by autor nastudoval dokumentaci, tak by vedel, ze DSC komprimuje po radcich“

Pokud by si předřečník nastudoval dokumentaci, tak by věděl, že DSC postupuje po řádcích pouze v rámci jednotlivých setů, tedy obdélníkových polí, na které je obraz rozdělený.

+1
+2
-1
Je komentář přínosný?

Aniz bych chtel byt hnidopich...ale technicky vzato je podle mne "bezstratova vizualni kompese" ve skutecnosti opravdu marketingovy blabol. Jakou objektivni metodou se da zjistit, jestli tam vizualne "nen videt rozdil"?
Mne to prijde podobny, jako porovnavat ruzne kodeky vuci originalu nebo mezi sebou..vizualne se tam casto nachazeji rozdily dost tezko, presto tam ale jsou :))
To stejny v hudbe, kdyz pouziji "HQ kvalitu" nejakeho ztratoveho kodeku...'99%' lidi nema zarizeni a sluch, aby treba rozdil mezi FLAC a mp3@320 poznalo..presto '1% silencu' tam ty rozdily slysi..a maji pravdu ;)

+1
+5
-1
Je komentář přínosný?

„Jakou objektivni metodou se da zjistit, jestli tam vizualne "nen videt rozdil"?“

Úplně stejnou metodikou, jakou se zjišťuje,v jakém rozlišení vidí člověk detaily, do jakého rozlišení vnímá projevy aliasingu nebo jako se vytvářejí psychovizuální modely pro kompresní algoritmy. Prostě se to otestuje na dostatečně širokém vzorku lidí, kteří budou z dvojice obrazů vybírat ten, který jim přijde kvalitativně horší, ve kterém vidí artefakty. S dostatečně velkým souborem srovnávacích vzorků a dostatečným počtem osob lze pak statisticky vyhodnotit, jestli výsledek odpovídá plus mínus náhodnému výběru (tzn. označili jako horší zhruba stejný počet originálních i komprimovaných obrazů) nebo je rozdíl vidět a jasná většina zvolených horších obrazů byla komprimována. To je v této branži zcela běžná a objektivní metoda.

+1
0
-1
Je komentář přínosný?

Nevím, jak je to přesně udělané, ale podle mého může "vizuálně bezztrátová komprese" na obraze klidně být reálná může. Je potřeba si uvědomit, jak jsou ta data "řídká" a udělat úplně bezztrátovou kompresi něčeho na monitoru jde mým odhadem asi tak v 99,9% případů (jednotlivých frame) klidně i s poměrem 10:1 - udělej si printscreen, ulož jej jako PNG a podívej se, kolik má.

Samozřejmě komprese obrazu na monitoru musí být o několik řádů rychlejší a jednodušší a musí fungovat už na nějaký parciálních částech obrazu, ideálně řádcích.

Podle mého (kdybych já navrhoval ten algoritmus, ha ha) bych to udělal prostě bezztrátově a ke ztrátové kompresi by docházelo až ve chvíli, kdy by tam přišelo něco, co by vypadalo jako nějaký zcela brutální šum. Jak pak implementovat tu ztrátovost? Třeba by šlo zachovat bezztrátový kompresní algoritmus pro jednoduchost implementace a začít zpožďovat a vypadávat snímky v rámci freesync. (Ono takto to stejně dopadne i u bezztrátového přenosu, když člověk pošle do monitoru kolikrát nějakou vizuální haluz, tak to nezřídka končí zobrazením nějakého "out of sync".)

+1
+1
-1
Je komentář přínosný?

ono zalezi na druhu hudby a dynamickem rozsahu, u nake napr. symfonicke skladby by to rozpoznal i "hluchy", ale u Katapultu asi nikdo...

+1
0
-1
Je komentář přínosný?

Principielne pravdu dis, nicmene rozlisovat rozdily mp3 320kb v nejvyssi kvalite vs flac zase tak jednoduche neni, ani u toho symf.orchestru ;)
Jenak potrebujes uz docela solidni aparaturu pro reprodukci a pak poznavat ty rozdily i tak neni uplne snadne, protoze se dostanes k 'hypisackym' pojmum jako 'barva zvuku', 'jasnost zvuku' 'detaily zvuku' apod.
Kazdy to urxite nepozna, ani kdyz bude mit kvalitni repro.

+1
0
-1
Je komentář přínosný?

Tidal ma pekny slepy test na 320kbps vs FLAC (resp. APE alebo co to pouzivaju oni) a skusal som to na Schiit Bifrost Uber + Lyr 2 + Audeze LCD 3 a v naprosto vacsine pripadov, som rozdiel nebol schopny poznat. A to sa rozhodne nepovazujem za hlucheho. :P

+1
+1
-1
Je komentář přínosný?

ad1) Cituji z https://www.quantumdata.com/assets/displayport_dsc_protocols_webinar.pdf : There are three (3) broad categories of compression in terms of the visual
effectiveness:
 Lossy compression such as MPEG and H.264 – Standard lossy image compression algorithms strive for “good enough.” They are irreversible. They exploit the fact that human visual system is unable to detect some spectral components.
 Visually lossless compression – Redundancy is removed but subjective tests show no appreciable loss.
 Lossless compression – The image after decompression is identical to the original. The process is reversible.

I zde se jasne zminuje, ze jde o subjektivne bezstratovou kompresi, cili jak rikam krasozvast, subjektivni hodoceni je irelevantni, kazdej to muze vnimat jinak. Nekteri testeri rozdil vidi, jini ne, to ovsem neznamena ze tam neni, pokud rozdil nevidim tak fajn, ale pokud ho uvidim, tak to proste bezstratova komprese neni, at si tomu rika kdo chce, jak chce, a v tomto pripade i samotna VESA pripousit, ze tam proste pozorovateny rozdil byt muze a je, i kdyz ne prilis casto a ne pro kazdeho. Vice to asi nema smysl rozebirat je to vec nazoru, ja osobne si myslim, ze kdyz ma neco nejakou udajnou kvalitu, tak to ma byt kvalita objektivni, nikoliv subjektivni, pokud Vy si myslite, ze subjektivni kvalita staci, tak dobre, brat Vam to nebudu.

ad2) Asi jste to nepochopil ale slices (tedy ty Vase sety) se za a) zpracovavaji obvykle paralelne, cili nijak neovlivni latence a b) rozdeluji vzdy jen jeden radek (i kdyz kazdy v celem snimku samozrejme). Takze nezbytny buffer je jak jsem uvadel ekvivalentni delce prave jednoho radku, takze zadne dalsi zpozdeni tam principialne neni nutne. Samotna VESA uvadi, ze DSC byl navrhovan s ohledem na nizke latence pro hrani a interaktivni vyuziti. Takze nevim kde jste dospel k cituji "řádově vyšší desítky milisekund lagu navíc" kdyz nezbytne zpozdeni bude v radu delky trvani jednoho radku, cili obvykle max. desitky mikrosekund.Mozna ze mate nejake interni informace, ze vyrobci schvalne pouziji vyrobne drazssi vetsi buffer (do ktereho se vejdou vyssi desitky milisekund videodat, ktere je potreba zpozdit) aby nasr.li hrace, kterym pak znovu prodaji draze vyrobne levnejsi hardware s mensi pameti, ale o tom ja nic nevim.

+1
+1
-1
Je komentář přínosný?

Ztrátová komprese se dá aplikovat v principu na 2 základní oblasti - obrazová data (tedy i video) a zvuková data. Pomíjím některé velmi specifické oblasti (třeba záznamy EKG...). Všechna ostatní data vyžadujeme komprimovat bezeztrátově (binárky, zdrojové kódy, texty, veškeré typy dokumentů...).

Takže podle vás tedy máme:
- vizuálně bezeztrátovou kompresi
- akusticky bezeztrátovou kompresi
- bezeztrátovou kompresi
????
:-)

Je mi líto, ale je to marketingový krasožvást. Máme jedničky a nuly. U nich není pochyb, zda došlo ke ztrátě kompresí či nikoli. Samozřejmě, že cílem každé ztrátové komprese není "rozdrbat data", ale snažit se co nejvíc přiblížit v rámci vnímání a potřeby bezeztrátovosti. To nic ale nemění na tom, že jde o kompresi v obecném případě ztrátovou.

Připomíná mi to dávné doby na tomto serveru, kdy se řešilo, zda pálené audio CD s identickými daty zní jinak (ploše...), než "originální lisované". ;-)

+1
0
-1
Je komentář přínosný?

Jeste jste zapomel na "pocitove bezestratovou kompresi", ta bude hitem pristiho leta :-) !
Proste kdyz budu mit pocit, ze je to bezestrat, tak je to O.K. .

+1
0
-1
Je komentář přínosný?

tvl, tak to je ignorant level RaStr.. si tu fakt obcas pripadam jak nekde na idnesu, kde si lidi prectou nadpis, maj z toho pocit ze sezrali salamouna a rovnou se jdou o obsahu co nevideli vykecavat do diskuse.. ((:

https://diit.cz/sites/default/files/styles/media_gallery_large/public/ic...

mas tam n_a_k_r_e_s_l_e_n_y jak to funguje, mas tam napsany ''independently encoded r_e_g_i_o_n_s'' a nakresleny ctverecky a ty tu neco placas o delce radku v palu.. ((:

+1
+1
-1
Je komentář přínosný?

Kdy nerozumite psanemu textu, tak to je tezke. "independently encoded r_e_g_i_o_n_s" znamena "nezavisle" enkodovane oblasti, v tomto kontextu rozumej soubezne, cili zadne extra zpozdeni se nekona. Je potreba ulozit maximalne cely jeden radek, to je proste teoreticke maximum, vice nezbytne neni. Samozrejme nikomu to nebrani ukladat vice, ale proc by to proboha delal, kdyz cely novy standard komprese byl navrzen prave proto, aby to delat nemusel ?!

+1
-2
-1
Je komentář přínosný?

Výborně, takže jsme se dostali k tomu, že se v rámci celého obrazu nepostupuje po řádcích, ale že je obraz v několika úrovních rozdělen na plochy. Pak už záleží jen na tom, kolik ploch zvládá enkodér paralelně zpracovat a zároveň zda stejně efektivně musí fungovat i dekodér. Podle všeho ne, když u displejů podporujících DSC dochází při použití DSC k výraznému zvýšení latencí než bez použití DSC.

+1
0
-1
Je komentář přínosný?

Nejsem autor VESA standardu a nenavrhoval jsem tento system, ale jak jsem ten popis chapal, tak obraz se zpracovava po radcich a ne po plochach a priznavam ze v tomto jsem se mylil. Kazdy radek tvori jednu nebo vicero zon, ty zony pak tvori svisle prouzky , resp. bloky. Nicmene vyska a asi i sirka tech bloku neni podle vseho pevne danna a je veci volby encoderu. Nicmene pro nejlepsi dosazenou kvalitu komprese je idealni co nejvetsi velikost bloku, coz dava smysl, protoze se jedna o statistickou kompresi a ta fuguje na vetsim vzorku dat lepe. Velky blok pak ale zase vyzaduje vetsi pamet a neumozni dobrou paralelizaci, cili nizkou latenci a take se pripadna chyba v prenosu projevi v celem bloku, takze je zaroven snaha volit velikost toho bloku co nejmensi. Vysledkem tedy asi bude nejaky kompromis. Kazdopadne napr. zde: https://www.semiwiki.com/forum/content/7127-vesa-dsc-encoder-enables-mip... pro 4K 60FPS 24-bit zdrojovy obraz uvadeji deleni na slices o vysce 144 radek, coz dava buffer o delce 1.1milisekundy, ostatne i cely frame trva jen 16.7milisekundy, tak proc by to melo pridavat zpozdeni v radu vyssich desitek milisekund mi stale jeste neni jasne. Dobra implementace by nemusela pridat vice nez radove par milisekund a i hodne spadne ne vice nez 1 frame, cili 20 milisekund pro 50fps zdroj (a pro nizssi fps zase neni obvykle DSC komprese vubec nutna). Mate pro sve tvrzeni o vyssich desitkach ms latenci nejaky zdroj ? Ja jsem zadny nenasel.

+1
0
-1
Je komentář přínosný?

Jaké tvrzení? Řeknu to tedy co nejjednodušeji a nejstručněji. Samotný fakt, že teoreticky může existovat implementace, která výrazným způsobem nezvyšuje latence, nijak nevyvrací možnost, že existují implementace, které latenci zvyšují výrazně. Podívejte se na prostý rozdíl v latenci mezi herními monitory a třeba monitory grafickými nebo multimediálními. Případně mezi monitory s rozlišením 720p a 5k, kde jsou i rozdíly přesahující úroveň řádu, přestože by z technologického hlediska nemusely být zdaleka tak velké.

Pokud tedy mám z jedné strany informaci, že u konkrétního monitoru jsou latence s DSC výrazně vyšší než bez DSC a na druhé straně mám tvrzení člověka - který daný monitor neměl v ruce - že DSC lze implementovat bez výraznějšího zvýšení latencí, tak nemohu druhou informaci chápat jako něco, co by vyvracelo tu první.

Jak už jsem psal ve článku, nemusí jít o finální stav a může se to týkat jen prvních produktů, na kterých se výrobci učí. Stejně jako první 4k monitory vykazovaly výrazně vyšší latence než současné.

+1
0
-1
Je komentář přínosný?

Počkat, něco mi tu nehraje. Takže všichni bečí jak je intel na prd s grafikou. Intel nestihá výrábět. Plýtvá křemíkem na grafiky které použivá sotva 1/5 jejich kupců. Teď se ještě přidalo AMD, které nabízí vyrovnanou konkurenci k jejich produktům. Intel nestíhá dodávat a přestat vyrábět procáky s grafikou a uvedené místo na wafru využít k výtěžnosti více čipů by byl logickým krokem.
Ale zrazu BUM!
Bublina splaskla a nic se nekoná ?
Ice-Lake bude mít zas polovinu čipu zaprasenou grafikou ?
WTF? Už to vypadalo že se pochlapí a ono nic... jak kdyby konkurence v podobě AMD neexistovala... nechápu.

+1
+2
-1
Je komentář přínosný?

V podstatě pravda. Taky bych ocenil spíš obyč CPUčko bez toho, čemu říkají "grafika". Nevím jak je na tom Intel v úvahách tímto směrem (ono to že to nedělají ještě neznamená že je to nenapadlo), ale já osobně to mám nastaveno takto :
Až chcípne hlavní grafika, na dobu určitou vytáhnu ze skříně rezervní GTX650. Teprve pokud by v rámci té *doby určité* zařvala i ona, začnu laborovat s tou UHD630 na procáku...

+1
0
-1
Je komentář přínosný?

Si kup XEON, ne? Ty nemaj grafiky a mas tam vice jader. A ze je drahej? No moc vas neni co chce takovy specificky produkt.. tak si holt priplatite.

+1
0
-1
Je komentář přínosný?

Jako na celeronu a i3 bych grafiku pochopil jako kancelářský stroj takto provozuji i5. Ale prostě šestijádrová i5 a výš s grafikou je prostě blbost, protože ji nikdo nebude provozovat bez externí grafiky. Jako na HD530-630 jako všechna čest co to umí, ale mohli by se trošičku zklidnit, jako nouzové zobrazovadlo fajn, ale jako plnohodnotná grafika na 5K už to tak trochu přehání. Nebo proč nevyrobí čistočistě CPU a neprdnou na to tu grafiku bokem jak tu Vegu? A k dostaní by byly prostě dva produkty i5 a i5+ (+ jako +GPU). Demence.

+1
0
-1
Je komentář přínosný?

To je blbost. Všichni tady leští osum let staré Thinkpady, které jsou rády za to, že mají vůbec HDMI a nejen VGA a že na tom rozjedou FHD při 60Hz. Jak můžeš vědět, co bude za pět let normální monitor? 4K/60 bude úplné minimum pro sekretářku na Excel, dnešní procesory, které mají být použitelné v kanceláři, to mají umět a tečka. Dokupovat do takových sestav levné grafiky je nesmysl, obzvlášť u různých "small factor" řešení. A že se do takových sestav nehodí i5? Proč jako? Dát tam "vždyť to stačí" dvoujádro a za rok a půl vyhodit a koupit další?

Že nejsou Intel procesory bez grafik přece nesouvisí s tím, že ty s grafikou mají morálně zastarat do dvou let. Ať ta grafika pěkně umí co nejvíc.

+1
0
-1
Je komentář přínosný?

Co je tohle za blabol?

"Určitou slabinou DSC z hlediska hráče je i fakt, že komprese a dekomprese může při použití některých zařízení přidat i řádově vyšší desítky milisekund lagu navíc"

Prave ze VESA DSC pracuje na urovni jednotlivych radku obrazu, takze nema proc vznikat zpozdeni vetsi nez.. 1/(120*2880) = 2.89 usec !

http://www.vesa.org/wp-content/uploads/2014/04/VESA_DSC-ETP200.pdf
"single line buffer"

+1
-2
-1
Je komentář přínosný?

Pro psaní komentářů se, prosím, přihlaste nebo registrujte.