Näytönohjainkiihdytystä Photoshoppiin
Näytönohjainavusteinen kiihdyttäminen tuntuu olevan tämän hetken vahva trendi ja jo aiemmin Adobe ilmoitti Acrobat-ohjelmistonsa tukevan kyseistä toimintaa. Aiemmin tänään uutisoimme myös Folding@home-projektista, jota voi pian käyttää GeForce-näytönohjaimilla niille suunnatulla client-ohjelmalla. Adobe on laajentamassa kiihdytystä myös kuvankäsittelypuolelle Photoshop-ohjelmistoonsa.
TG Dailyn uutisoinnin perusteella seuraava julkaistava Photoshop-versio tukee kiihdyttämistä näytönohjaimella ja sivuston näkemän demonstraation perusteella jälki on vakuuttavaa. Kyseinen ohjelma kulkee koodinimellä Stonehenge ja se tullaan julkaisemaan todennäköisesti Photoshop CS Nextinä tai Photoshop CS4:nä (Creative Suit). Ohjelmaa voidaan odottaa markkinoille näillä näkymin lokakuussa.
Adobe oli demonstroinut toimintaa Intelin Skulltrail-laitteistolla kahden gigatavun eli 442 megapikselin kokoisella kuvatiedostolla ja käsitellyt sitä kuten nykypäivän kameralla napsittua muutaman megapikselin kuvatiedostoa. Kuvaan oli tehty muutamia zoom- ja käännösoperaatioita ja näitä oli kyetty suorittamaan lähes viiveettömällä tahdilla. Tulevassa Photoshopissa tulee olemaan myös mahdollisuus 3D-mallien tuomiseen, jonka pintaan voidaan lisätä esimerkiksi tekstiä tai väriä ja renderöidä tämän jälkeen.
TG Daily, Photoshop to get GPU and physics acceleration
Ville Suvanto
Onko näytönohjainavusteisella kiihdyttämisellä tulevaisuutta?
- 1.
-
Mitäpä sitä enää näytönohjainta turhana lepuuttamaan kun laskentatehoa löytyy vaikka muille jakaa.
- 2.
-
Ohhoh! :O Hyvä hyvä
- 3.
-
Tätä on odotettu! Olis valokuvaajille hyvä uudistus jos tapahtuis hommat (myös) GPU:lla. On meinaan oikeasti isojen kuvien kääntely edelleen aika nihkeää.
- 4.
-
Jaa-a. Milloinkohan nähdään GPGPU Linux.
- 5.
-
Tuolla pääsee kenties hiukan taasaamaan sitä prossutehon tarvetta. Tällä hetkellä sulavaan ISOJEN tiedostojen käsittelyyn joutuu hankkimaan aivan poskettomia laitteita.
- 6.
-
Enää ei tarvita muuta kuin yhtenäinen rajapinta näyttiksille, ettei tartte hommata erikseen ajureita jotka sopii nVidian ja ATin näyttiksiin, tai S3:n tai Intelin yms.
- 7.
-
WANHA!!! Photoshopin toimintoja kiihdyttäviä kortteja oli olemassa jo 90-luvun puolessä välissä. Mäkille.
- 8.
-
Corel Paint Shop Pro Photo:lle vastaavaa odotellessa :)
- 9.
-
Saisivat kanssa videonkäsittelyn toimimaan tuolla. Meinaan on vähän joskus takkuista noilla kovemman luokan ohjelmilla pelehtiä efektien kanssa. Olisi GPU-kiihotus siihen omiaan.
- 10.
-
Onhan noita ainakin Pinnaclella ollut video-editointi softia jossa gpu:takin hyödynnetään.
- 11.
-
Applen Aperturehan on käyttänyt GPUta jo vuosia. Tietysti hyvä jos tekniikka yleistyy.
- 12.
-
On se hienoa, miten tällaiset asiat olevinaan hoksataan kymmenen vuoden viiveellä vaikka se on ollut mahdollista siitä lähtien kun 3D-kortteja on ollut olemassa. Ihmisen ahneus asettaa tekniikalle keinotekoisia rajoja vaikka väkisin.
- 13.
-
Miksi artikkelissa ei mainita, että Folding@home toimii jo nyt Radeon korteilla?
http://kureng.wordpress.com/2008/04/17/foldinghome-gpu-client-for-ati-radeon-hd-2xxx-hd-3xxx-series/ - 14.
-
vielä kun saisivat x64 versiot ulos
- 15.
-
koskahan seti@home rupee käyttään näytönohjaimien tehoja?
- 16.
-
Siinä vaiheessa kun kaikki näytönohjaimet tottelevat samaa käskyä, eikä tarvi miettiä että minkä firman kortti siellä lojuu.
Oikeasti. Tietokoneisiin ei tarvita erikseen näytönohjaimia tai fysiikkakortteja, vaan yksinkertaisesti yleiskäyttöinen matriisilaskentakortti jossa on iso kaistanleveys ja oma muisti.
Näitä sitten käytettäisiin laskemaan mitä tahansa SETI projekteista pelien grafiikoihin. Pelien tekemisessäkin tulisi paljon enemmän vaihtoehtoja, kun voisi käyttää tehokkaasti esim. voxeleita pelimaailman muodostamiseen. Näitä kortteja voisi laittaa rinnakkain helpommin kuin näytönohjaimia, koska toisen kortin ohjelmoiminen ei eroa sen kummemmin sen ensimmäisen ohjelmoinnista. Niissä on vain monta rinnakkaista prosessointiputkea jotka voidaan jakaa eri säikeiden käyttöön. Ihan sama millä fyysisellä kortilla ne putket ovat.
Varsinainen näytön ohjainpiiri voi olla silloin integroituna emolevylle, koska se ei tee mitään työtä. Se toimii vain yksinkertaisena framebufferina, ja kenties osaa piirrellä yksinkertaista grafiikkaa silloin kun lisäkortit ovat virransäästössä.
- 17.
-
Pieni kirjoitusvirhe tuolla: ”creative suit” kun pitäisi olla ”creative suite”
- 18.
-
@16, voi luoja sitä standardisotaa, kun niillä tuntuu jo nytkin olevan herneen nenässä ties mistä.
- 19.
-
@16, ei tule tapahtumaan. Jos katsotaan minkä tahansa elektroniikkalaitteen historiaa, niin laskentatehoa kaivataan aina vain enemmän, mikään ei riitä. Koska tehot ei riitä, toiminnot jaetaan pienempiin kokonaisuuksiin, joihin jokaiseen pystytään tekemään siihen erikoistunut laskentayksikkö. Ehdottamasi yleiskäyttöinen laskentayksikkö olisi ajatustasolla mukavan yksinkertainen ratkaisu, mutta siitä saatavat tehot eivät vain mitenkään pystyisi kilpailemaan CPU+GPU yhdistelmälle.
- 20.
-
@18
Ai niinkuin x86 prossuissa käyty standardisota?@19
Miten niin? Tehdään vaan tehokkaampia kortteja tai asennetaan niitä useampia että saadaan lisää vääntöä. Suuntaus on kuitenki se että samanlaista laskentaa tarvitaan moneen eri asiaan, ja on järjetöntä tehdä koneeseen n+1 erillistä korttia jotka suorittavat täsmälleen samanlaisia laskutoimituksia kukin omalla raudallaan.Fysiikanmallinnusta tehdään nykyisin GPU:lla, grafiikkaa tehdään GPU:lla, tietellistä laskentaa tehdään GPU:lla, nyt sitten myös kuvankäsittelyä, seuraavaksi signaaliprosessointia ääniefektejä ja musiikin tekemistä varten, kryptografiaa, elektroniikkasimulaatiota, lujuusanalyysiä jne. jne.
On vain ajan kysymys milloin myönnetään että se GPU ei ole oikeastaan vain näytönohjain, vaan se on yleiskäyttöinen matriisiprosessori.
- 21.
-
@19
Ei tietenkään millään erilliskortilla kilpailtaisi CPU:n kanssa, vaan nykyisen GPU+CPU yhdistelmän tilalle tulisi CPU+”MPU” koska matriisilaskentaan erikoistuneet prosessorit eivät pärjää erityisen hyvin haarautuvissa ohjelmissa. Niiden tarkoitus on vääntää valtavat määrät dataa yhdestä muodosta toiseen muotoon, eli suorittaa se raaka työ mihin CPU:lla ei riitä rahkeet.
- 22.
-
@ite, matriisiprosessori? Mitä iloa siitä olisi? Paljon enemmän onnea tuottaa jos multiply-accumuate on atominen toiminto; tollasella tekee jo melkein mitä vaan. Tollanen vektori kertaa matriisi olisi neljä madd operaatiota.
// r2 = a (vec4)
// r3, r4, r5, r6 = b (mat4)
// r1 = a * b
mul r1, r2, r3
madd r1,r1, r2, r4
madd r1, r1, r2, r5
madd r1, r1, r2, r6Jos ei o erillistä ”mul” käskyä, niin sitten toi aika mul olisi:
mul r1, r0, r2, r3
r0 on rekisteri mikä on nollattu, tai sitten arkkitehtuurissa se voi olla rekisteri josta lukeminen antaa aina nollan ja johon kirjoittaminen on nop.
Sitten käskyjen enkoodaukseen lisätään swizzling ja writemasking, negate komponenteille; näin ei tarvita erillisiä ”negate” tai ”sub” käskyjä. Jakolasku ois aika pro, neliöjuuri ois kiva, ehkä myös 1/sqrt(n), sin/cos ja jotain pientä sälää.
Note! Aika usein näyttäis olevan tapana että output port ois yksi input porteista madd käskyssä, säästää enkoodaus tilaa. Mulla tossa yllä tosiaan oli formaatti:
madd result, a, b, c
// result = a + b * cYleisempi ois ollu:
madd result, a, b
// result += a * bMutta hällä-väliä. Noi ns. stream prosessorit joita GPU:issa on toimii aika pitkälti tällä tavalla.
- 23.
-
multiply-horizontal-add käsky ois kans aika kiva extra (mhadd) (aka. dp);
dp r1, r2, r3
// r1.x =
// r1.y =
// r1.z =
// r1.w = r2.x * r3.x + … r2.w * r3.wvec4*mat4 olisi:
dp r1.x, r2, r3
dp r1.y, r2, r4
dp r1.z, r2, r5
dp r1.w, r2, r6Tosin tässä tapauksessa se 4x4 matriisi olisi madd version matriisin transpose. Jos tota skalaarituloa ei olisi käskynä ei silti paljoa menetettäisi. Tosin jos tehdään vain pistetulo se olisi kalliimpi ilman ko. käskyä:
mul r1, r2, r3
add r1.xy, r1.xy, r1.zw
add r1.x, r1.x, r1.yKaksi add käskyä voi ”simuloida” horizontal addiä kun käyttää swizzlea (component select) ja write maskia. Onhan se aina iso ilo jos sen saa yhdellä käskyllä. Noi addit voi olla maddejä:
madd r1.xy, r1.zw, r0, r0
jne.Mitä iloa siitä on että on vähemmän erilaisia käskyjä? Se ilo, että siellä ei ole se ”dp” unitti hengailemassa turhana suurimman osan ajasta, jos sen simulointi vie 3 käskyä ja niillä transistoreilla saadaan toteutettua 1,5 kappaletta madd unitteja, niin niitä on silloin varaa ”polttaa” extra käskyjen suorittamiseen ja näin saadaan enempi irti pinta-ala investoinnista. Lähes sama teho samasta pinta-alasta irti vaikka käskyjä suoritetaan useampia!
Kysymys herää kannattaako madd unitti vielä pilkkoa erikseen add ja mul unitteihin.. jos näin tehdään, voidaan näitä unitteja kierrättää add, mul, madd, dp, jne. käskyjen toteuttamiseen .. esim. dp4 käyttäisi 4 mul ja 3 add ”resurssia”. madd olisi 1 mul ja 1 add resurssi jne.
Mielenkiintoisin osa arkkitehtuurissa ei olisi miten noi unitit on toteutettu vaan miten data ohjaillaan paikasta toiseen. Yllättäen myös latenssi olisi ”jännä juttu” jos asiat tehtäisiin tuolla mekaniikalla, esim. dp4 toteutukseen olisi monta tapaa.
Esim, laskutoimitukset voitaisiin tehdä peräkkäin:
a = w*w
b = z*z
a = a + b
b = y *y
a = a + b
b = x*x
a = a + bHui, 7 eri toimintoa ketjussa.. kivat latenssit. Entäs rinnakkain?
a=w*w, b=z*z, c=y*y, d=x*x
a = a + b, c = c + d
a = a + cTon paremmin tota ei voi atomisilla operaatioilla rinnakkaistaa, koska toi ekat kaksi addia ovat riippuvaisia 4 ekan multiplyn tuloksista. Niitten pitää valmistua. Sama juttu vikan addin kanssa, riippuu ekoista addeistä, right?
Eli toi erilliset add-mul unitit olisi siis latenssirysä. Tosin tuo ei ole ongelma koska laskenta on ”massiivisen rinnakkaista”, meillä on satoja (vähintään) duuneja ajossa. Jos meillä olisi seriaalinen prosu kuten CPU, latenssi olisi suurempi ongelma.. tuota ongelmaa vastaan on todella kirjavia ratkaisuja prosumailmassa: käskyt ajetaan mahdollisimman aikaisin, ”out of order” sitä mukaa kun sisääntuleva data on valmiina jne.
p.s. I'm gay
