AMD: Det skal være lettere at programmere til grafikprocessoren

Grafikprocessorernes stærke sider er for svære at udnytte. Chipproducenterne vil gøre arbejdet lettere for softwareudviklerne, så grafikchippen kan bruges til eksempelvis at sænke strømforbruget.

STOCKHOLM Det nyeste trick til at forbedre ydelsen i processorer, som chipproducenterne har trukket op af hatten, er brugen af grafikprocessorer til mere generelle beregninger. Men det giver nye udfordringer for softwareudviklerne, som producenterne nu forsøger at løse.

Grafikprocessorer var tidligere meget specialiserede processorer, men udviklingen har gjort det let og billigt for chipproducenterne at integrere en mindre grafikprocessor på samme chip som den almindelige hovedprocessor.

Grafikprocessoren, eller GPU'en, er utrolig kraftig til visse parallelle regneopgaver, men fordi processoren ikke kan fodres med hvad som helst, er den også sværere at programmere til. Hvis den ekstra regnekraft skal udnyttes, skal der derfor nye værktøjer til.

»Hvorfor er der ingen, der bruger GPU'en, når den sidder med fem gange så mange gigaflops som CPU'en? Fordi det er svært. Vi er nødt til at gøre det lettere,« siger marketingchef Sasa Marinkovic fra AMD's pc-processorafdeling til Version2.

Udviklerne har fået flere udfordringer i takt med, at processorerne er blevet mere komplekse. Det første store spring var skiftet fra én enkelt kerne til flere kerner. Selvom det er 10 år siden, flerkerneprocessorer dukkede op til x86-platformen, så er det stadig vanskeligt at udnytte det i applikationer, fordi man som udvikler skal tænke over at bruge flere kerner på samme tid.

Nye udviklingsværktøjer har dog til en vis grad gjort det lettere, men mange applikationer bruger fortsat kun én kerne på processoren.

Et tilsvarende problem gør sig gældende for GPU'en. Der findes værktøjer som CUDA og OpenCL, som er beregnet til at udnytte en grafikprocessor, men de bruges hovedsageligt til specielle formål.

»Der er mange flere programmører, som ved, hvordan man optimerer til CPU'en, end der findes til GPU'en. Derfor vil vi gerne give udviklerne mulighed for at bruge de samme værktøjer til GPU'en,« siger Sasa Marinkovic.

AMD har sammen med flere andre chipproducenter som eksempelvis ARM, Samsung, Qualcomm og Texas Instruments stiftet Heterogeneous System Architecture Foundation, som arbejder på åbne standarder, der skal gøre det lettere at programmere til chips, der kombinerer CPU og GPU.

Et af projekterne er en forenet hukommelsesmodel, som skal gøre det lettere at arbejde med at flytte data mellem GPU- delen og CPU-delen af chippen. Ved at dele hukommelsen kan man tilgå de samme områder fra begge processorkomponenter mere enkelt.

Målet er desuden at gøre de åbne standarder fælles for forskellige arkitekturer, så det fungerer på samme måde, uanset om man programmerer til en x86-processor eller en ARM-processor.

Grafikprocessoren kan klare visse parallelle opgaver langt hurtigere end CPU'en, og én af fordelene ved at udnytte GPU'en kan derfor være bedre batteritid, hvis en applikation kan afvikle sine beregninger hurtigere, så processoren kan tilbringe mere tid i hviletilstand.

Strømforbruget er én af de største udfordringer for de fleste chipproducenter, men selvom flere allerede fremstiller chips, som har indbygget GPU, så er åbne standarder nødvendige for at applikationerne begynder at udnytte GPU'en.

»Vi skal lade udviklerne om at programmere, og så kan chipproducenterne konkurrere på den hardware, de kan levere til at understøtte standarderne,« siger Sasa Marinkovic.

Version2 var inviteret til Stockholm af AMD.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Thomas Søndergaard

Det nyeste trick til at forbedre ydelsen i processorer, som chipproducenterne har trukket op af hatten, er brugen af grafikprocessorer til mere generelle beregninger.

Nyt og nyt. Jeg kan huske at have deltaget i et 1-dags GPGPU arrangement i forbindelse med SIGGRAPH 2004. Den gang var det vist rimeligt nyt.

  • 3
  • 0
#2 Deleted User

Jeg har installeret Intels OpenCL SDK og har kørt Luxmark v.2.0. på både CPU og GPU. Der var ikke så stor forskel på resultatet i Sala testen. Det er måske fordi jeg bruger en GeForce 670 GPU og der er stor latenstid over PCIe bussen? Hvis man "glemmer" at intallere Intels OpenCL driver, så bliver CPU scoren ganske ringe. Sammensværgelse ? Ellers er GPU'en hurtig til videoomkodning i Nero Recode versus en 6-kerne i7. 7 minutter mod 30 minutter på CPU'en. Til gengæld er kvaliteten af videoen dårligere. Og stabiliteten ? Oh la la. Jeg kan ikke bruge maskinen mens den omkoder. Så går det galt. Det går også ofte galt i videoafspillere der bruger GPU'en til opskalering/afkodning. Især i Blu-Ray film. Nogen der kender et godt program? Med Handbrake 0.99 kan man bruge en integreret GPU til videoomkodning. Ihvertfald intels GPU. Nogen der har prøvet det?

  • 1
  • 0
#3 John Vedsegaard

det er beklageligvis også sådan at manualler til grafikkortene i sig selv, kan være meget vanskelige at fremskaffe. En ting er jo at programmere via opengl, men vil man skrive direkte til kortet, kræver det viden om registre og andet, det beskrivelse er ofte ikke så nem at komme i forbindelse med. Grafikkort er jo alt andet end ens, hvilket ikke er så væsentligt hvis man bruger openGL, der tager højde for den slags, men skriver man direkte til kortene er historien en anden.

Jeg ved godt dette er ekstremt, og kun anvendes til helt specielle programmer, men det illustrere meget godt hvor producenternes problem ligger.

Nogle af de tidligere applikationer vi lavede, blev udviklet via GLscene, som kan meget. Men senere har vi ændret helt på dette og bruger nu kun egen udvikling, som netop skriver direkte til kortet. At vi så er begrænset til få kort og producenter af kort, gør ikke så meget i vores tilfælde.

Men tekniske manualler er ikke så nemme at få fat i, selv om det er blevet lidt bedre med årene.

  • 0
  • 0
#4 Sune Marcher

Jeg ved godt dette er ekstremt, og kun anvendes til helt specielle programmer, men det illustrere meget godt hvor producenternes problem ligger.

Kan du give nogle reelle eksempler - med nutidig hardware - hvor direkte programming af en GPU giver fordele i forhold til at gå igennem et af standard API'erne? (Udover drivere, naturligvis).

AMD's Mantle API (der godt nok ikke er bare-metal, men stadig væsentligt tættere end både DirectX/DirectComputer og OpenGL/OpenCL) har ikke givet imponerende resultater indtil videre, og jeg ville være ret ked af at gå tilbage til præ-DirectX fragmenteringen. S3 ViRGE vs 3dfx/Glide vs Verite vs halvjertede OpenGL miniports... ugh. OK, et API som Mantle kan i teorien porteres, men det har Nvidia næppe den store interesse i at deltage i - og jeg er heller ikke sikker på det er et fornuftigt abstraktionsniveau at befinde sig på til de fleste ting.

Og bare-metal adgang? Selv ikke spillekonsollerne programmeres på det niveau i dag.

  • 0
  • 0
#5 Claus Jacobsen

Der er nu en ret stor forskel i performance. MEN det afhænger i meget høj grad af applikationen og hvordan den ellers er i stand til at understøtte multithreading.

Et af problemerne med videoencoding baseret på OpenCL er den manglende understøttelse af Lookahead (altså i bogstaveligste forstand at kunne buffer og "forstå" hvad der sker i frames fremadrettet i forhold til den frame man arbejder på. Det har været en meget stor hurdle i x264 og er pt kun bygget ind på experimental stadiet. Nero Recode og andre løsninger bruger desværre fastlagt algoritmer i grafikken til først at decode (og det er her vi får den forbedrede performance i øjeblikket) og det er lige netop det der er problemet med dem. De er 100% fastlagte og kan ikke ændres da de er bygget ind i HW. Så snart man begynder at lave en SW-baseret udgave der kan tweake billedkvaliteten ryger performance fuldkommen til gulvet. (Til gengæld er vi pt nødt til at gøre det her til encoding af h265 for CPU-mæssigt der er godt nok lang vej hvis en cpu skal encode 4K materiale i H265. - se mere om det i forummet på www.doom9.org)

Nu startede jeg med at sige at der er forskel i performance afhængig af applikationerne. HVIS de er specifikt skrevet til openCL baseret brug (og intel har jo en hybrid driver der fungerer så du kan køre både CPU og GPU med samme kodebase) så er der enorme gevinster at hente. Stort set alle applikationer der i dag køres i de danske og udenlandske supercomputing centre er efterhånden lavet til at køre i enten opencl eller Nvidia CUDA. med MARKANTE forskelle i performance i forhold til alm cpu-beregninger (i visse applikationer har jeg hørt om hastigheder på mellem 20-50x hurtigere). De første danske supercomputere jeg har kendskab til der kørte specifikt skrevne applikationer er fra omkring 2009-10.

MEGET store databaseapplikationer er også så småt begyndt at være i stand til at udnytte GPU'erne til at lave beregninger. (SAP) og i og med at man har muligheden for at lave remote direct memory access i et cluster på tværs af GPU OG CPU'erne så er der potentielt set RIGTIGT meget performance at hente hvis man smider en stak Quadro/firegl ind i serverne. - Men der er stor forskel i driverfokus på de professionelle grafikkort og så dem til alm hjemmebrug. Selvom de kort til hjemmebrug faktisk er i stand til at performe bedre rent teknisk. (der skal åbenbart være en årsag til at man skal punge 6x prisen på et alm grafikkort for at få et professionelt kort)

  • 0
  • 0
#6 Sune Marcher
  • 0
  • 0
Log ind eller Opret konto for at kommentere