Intel släpper Media SDK 2013 – Quick Sync för öppen källkod

Är detta något man bör ladda ner om man kör någon av dessa processorer eller är det bara för dom som sysslar med videoredigering etc?

Och det är egentligen bara för de som har långsammare processor (då QuickSync är lika snabb på allt från 2-kärniga laptops till 4+4-kärniga desktops).
Med de snabbare desktop-CPUerna är x264 snabbare om kvaliteten dras ner till samma nivå. Dock givetvis med maxad CPU-användning medan QuickSync lämnar processorn fri till annat.

Därför det var värt att nämnas =). Kom på det där i slutet, så kanske inte bara för långsammare processorer, men mest användbart där.

Kan inte låta bli att peka på en sak i det som länkas av Zotamedu ovan då det belyser varför trenden med att öka antal CPU-kärnor har stannat på 4/8, det är inte p.g.a. lata/okunniga programmerare utan att väldigt många problem helt enkelt bara kan dra begränsad nytta av många CPU-kärnor.

As we’ve been noting in our GPU reviews for quite some time now, there’s no advantage to transcoding on a GPU faster than the $200 mainstream parts. Remember that the transcode process isn’t all infinitely parallel, we are ultimately bound by the performance of the sequential components of the algorithm. As a result, the Radeon HD 6970 offers no advantage over the 6870 here. Both of these AMD GPUs end up being just as fast as a Core i5-2500K.

Virtual Void #10
Intressant.
Det får ju en att undra hur AMD egentligen tänkte när dom gick all in med BD?
Det får ju också en att undra över hela HSA-tanken?

Funderingar på kammaren:
Varför, satsade man inte istället på en arkitektur som är skalbar på ett djupare plan. Jag tänker ungefär så här:
1 "modul" med "4" kärnor, vars resurser antingen kan delas upp på 1-2-4 trådar, och därmed använda alla trissor som finns tillgängliga? Låt säga att vi har ett program som endast använder 1 tråd effektivt, då skulle mitt tankefostret använda alla 4 kärnor som om dom vore en enda?

Ok, kanske knepigt att få till i praktiken?

/Jacozz

Att göra en CPU som utför väldigt mycket per klockcykel är väldigt mycket svårare än att klämma dit ett gäng relativt simpla CPU-kärnor. Att vi ser så liten förändring i IPC (Instructions Per Clock) är helt enkelt därför att det blir exponentiellt svårare att extrahera parallellism ur ett enda instruktionsflöde för varje förbättring man gör. Det betyder att plottar du IPC (y-axel) mot antal transistorer du slänger på problemet (x-axeln) så får då en y = ln(x) liknande kurva.

Quick Sync är ett exempel på vad man kan göra med relativt få transistorer. Quick Sync är en s.k. fix-funktions krets, d.v.s den är relativt begränsad i vad den kan utföra men å andra sidan kan den utföra den uppgiften väldigt snabbt, med få transistorer och samtidigt dra lite ström relativt ett mer generiskt chip som en GPU eller än mer än CPU. Våra smarta telefoner innehåller ofta flera sådana här fix-funktions chip just p.g.a. att de dra så lite ström i förhållande till att utföra samma sak med CPUn (även om det är en ARM).

Så inte alls omöjligt att det är just sådana här fix-funktions-block vi kommer få se mer av i framtiden när krypningar tillåter fler transistorer på en given yta, då det kommer ge ganska lite att använda de extra transistorerna till att öka IPC.

Bra enkeltrådad prestanda uppnås genom att göra ofantliga mängder gissningar på vad som händer i framtiden och beräkna dessa parallellt. När man väl kommer dit så har man potentiellt redan räknat klart saker om man gissat rätt. Framtidsgissningarna beror på vad som händer innan, så man kan inte veta säkert innan man faktiskt kommer dit.
En annan sak man kan göra är att öka mängden cache för att minska antal gånger man får hämta data från det otroligt långsamma RAM-minnet, men om allt redan fick plats i cache så hjälper det inget.
Sen kan man givetvis höja klockfrekvensen på bekostnad av energiåtgång och instabilitet.

Intel har otroliga resurser till att utveckla det första, och ändå ha plats över på kretsen till det andra. Frekvenserna har de varit lite konservativa med som syns på hur mycket man kan överklocka, och även för att de sakta men säkert kan öka den för varje generation för att "verka bättre".
AMD kan inte följa i Intels fotspår, så det finns inte mycket annat att göra än det enkla - smälla in ett antal sämre kärnor och hoppas att folk kommer ha användning för dessa.

Japp, och om AMD kom med någonting som kunde hota Intel skulle dom genast släppa processorer med sådär 500MHz högre klockfrekvens utan problem.

Intel vill också jobba hårt på att undvika att gå samma väg som dom gjorde med Pentium 4 och fokuserar helhjärtat på energieffektivitet och nya funktioner nästan.

Lite tråkigt för oss, hade AMD hotat hade vi sett mer utveckling inom andra områden, men jag tror detta är en bra utveckling i längden även om det är lite tråkigt just nu...

Ett annat exempel på fix function som ligger nära till hands är ju chipen som sitter i enklare mediaspelare. De äter tung HD-film som även lite nyare processorer får jobba lite på till frukost och drar så lite effekt att de utan problem kan kylas passivt. Men de kan i princip bara avkoda film. Får de ett format som de inte stödjer är det kört och de orkar knappt ge flyt nog i ett GUI. Undrar om inte det blir nästa steg även för Intel. Slänga in lite mer dedikerad videoavkodning istället för att "bara" dumpa över det på grafikkortet. Det känns ju som något som de skulle kunna spara in väldigt mycket ström på när det kommer till laptopar och plattor som ju inte sällan används för just film.

Men hallå?
Tack för infon Virtual.
Eftersom jag inte egentligen förstår hur en processor fungerar, så får du ta mina frågor lite som du utbildar på en AMS-kurs

Eftersom du förklarade att singeltråds-prestanda snarare beror på att kunna "gissa rätt" än antal transistorer tillgängliga för beräkning, betyder det då att när man "gissar", således preloadar tidigare instruktioner från L1, L2 resp L3cache och "jämför dessa istället för att processa en helt ny körning?

Är det korrekt tänkt?

Jacozz

Finns redan hos alla Intel-CPUer sedan flera år tillbaka.
Och vad var felet med DXVA på grafikkort innan?

Skillnad i strömförbrukning. Min laptop klarar HD-material om det körs på Intels grafik men det är tungt för den och den drar en del ström vilket märks på batteritiden och på fläkten. Samma film klarar en WD Live av med en krets som kyls passivt i en liten plastlåda. Utan DXVA vill den inte spela vissa HD-filmer utan lagg. Så det känns som om implementationen skiljer sig lite.

Jag hittar inte källkoden. Var det inte öppen källkod?

"With the release of the Intel Media SDK 2013, Intel open sourced its dispatcher code. The dispatcher simply detects what driver is loaded on the machine and returns whether or not the platform supports hardware or software based transcoding. The dispatcher is the final step before handing off a video stream to the graphics driver for transcoding, but previously it was a proprietary, closed source piece of code. For open source applications whose license requires that all components contained within the package are open source as well, the Media SDK 2013 should finally enable Quick Sync support. I believe that this was the last step in enabling Quick Sync support in applications like Handbrake."

http://www.anandtech.com/show/6665/intels-quick-sync-coming-s...

Allt är inte Open Source men tydligen är tillräckligt mycket det för att folk ska vara nöjda.

Tack för förklaringen virtual void!
Det uppskattas

/jacozz

Tycker det verkar lite svårtolkat men om det ska funka på Linux måste det väl uppfylla GNU-licens eller någorn kompatibel licens antar jag. Jag kör ju enbart Linux numera hemma på mina datorer (utom på bärbar dator där jag har dual boot). Kan detta betyda att detta alltså har möjligheter att bli äkta fri källkod som kan fungera i Linuxmiljö? Känns ju lite trist om den måste detektera windows-drvrutiner innan det blir åtkomligt.

Å andra sidan så får man bättre kvalitet med x264 i minst samma hastighet om man har en stark CPU. Men som någon skrev det kan ju finnas applikationer där man vill avlasta CPU och där toppkvalitet inte är högsta prioritet. Funderar faktiskt på att köpa mig ett intelsystem med integrerad grafik så detta är ju jättetrevliga nyheter om de kan få det helt fritt utan hindrande licenser eller spärrar för fria operativsystem.

Hade missat att de byggt om det så mycket även på avkodningen.

Den öppna källkoden är alltså enbart är en enkel wrapper som dynamiskt laddar det proprietära MSDK-librariet och passar vidare anrop till den. Inget stöd för att tillåta utvecklare att göra egna anrop till lågnivåfunktioner.

Antagligen i samband med att QuickSync introducerades. Man måste ju kunna avkoda filmen innan man encodar den igen =).
Snabbaste sättet att komma åt avkodningen är just via Quicksync (även på budget-CPUer som "inte har" Quicksync), fast det i praktiken är samma sak som DXVA.