NO334888B1 - Fremgangsmåte for automatisk å generere tegneoperasjoner fra grafikkressurser - Google Patents

Abstract

Fremgangsmåte for automatisk å generere en tegneoperasjon på ethvert grafikkundersystem basert på grafikkressurser definert uavhengig av hverandre. Fremgangsmåten omfatter å etablere en uttrykksgraf basert på spørring etter parametere som er nødvendig for tegneoperasjonen og å splitte uttrykkgrafen inn i isolerte deler med uttrykksgrafer ved grensen av ulike eksekveringstrinn og å konvertere hver isolerte uttrykksgraf til konvensjonell kode.

Description

Framgangsmåte for automatisk å generere tegneoperasjoner fra grafikkressurser

Introduksjon

Den foreliggende oppfinnelsen omhandler en metode for automatisk å generere en tegneoperasjon for et grafikkundersystem basert på et sett med grafikkressurser.

Bakgrunn

Feltet innen datamaskingrafikk omfatter teori, fremgangsmåter og teknikker for å omforme et sett med grafikkressurser (graphic assets) til visuelle bilder. Grafikkressurser finnes i et utvalg av formater, slik som: • geometriske former definert av matematiske funksjoner, punkter, kanter, eller polygoner, • attributter definert i forhold til geometriske former som beskriver tiltenkt utseende og oppførsel til formen i respons til omgivelsesbetingede egenskaper, slik som funksjoner som beskriver hvordan formen samhandler med ulike fysiske eller optiske fenomen, • teksturbilder som er koblet (mapped) til geometriske former for å gi ekstra overflateinformasjon med verdipunkter for slike attributter over formen, • data som beskriver animasjon av geometriske former og deres attributter over tid, eller i respons på input eller omgivelsesbetingede triggere, eller • datamaskinprogrammer som beskriver hvordan data brukt for å beskrive en visuell fremtoning eller oppførsel til en grafikkressurs skal beregnes.

Et grafikkundersystem er en innretning som, gitt et sett med data, programmer og parametere tilhørende et sett med tegneoperasjoner, kan fremstille (render) et visuelt bilde i et ønsket outputmedium. Et datamaskingrafikkundersystem er ofte implementert ved hjelp av en GPU (Graphics Processing Unit) og en software driver som tilbyr et grafikk API (Application Programming Interface) som definerer et sett med tegneoperasjoner og deres inputparametere, slik som OpenGL eller Direct3D. Et annet eksempel på implementering av grafikkundersystemer kan være en printer hardwareinnretning, en software driver som tilbyr et grafikk API sett med mulige tegneoperasjoner og deres inputparametere for printeren.

En vanlig teknisk utfordring på området med datamaskingrafikk er å konvertere grafikkressurser i ulike formater til effektive tegneoperasjoner for et gitt undersystem. Tidligere kjente fremgangsmåter og teknikker omfatter å omforme grafikkressurser mellom ulike datarepresentasjoner, og så å anvende manuell teknikk for å utvikle en domenespesifikk software-applikasjon som tar grafikkresurser i en passende datarepresentasjon og konverterer dette til tegneoperasjoner for et grafikkundersystem på en fast definert måte som er passende for applikasjonsdomenet. Denne prosessen blir ofte dyr og krever spesialistkompetanse.

US-2012/0029676 Al beskriver en fremgangsmåte og system for automatisk å generere en samordnet tegning av et prosjekt, hvor fremgangsmåten omfatter å legge inn parametrisk informasjon og få tilgang til en fil assosiert med en skjematisk tegning av et prosjekt og å identifisere et flertall elementer i den skjematiske tegningen. Fremgangsmåten omfatter videre tilegnelse av geometrisk og tilkoblingsinformasjon assosiert med hvert flertall av elementer. Fremgangsmåten omfatter i tillegg å velge ett eller flere forhåndsdefinerte objekter fra en database basert på geometrisk og tilkoblingsinformasjon assosiert med hvert flertall av elementer og innmatet parametrisk informasjon. Fremgangsmåten omfatter videre automatisk generering av en koordinert tegning av prosjektet ved hjelp av én eller flere forhåndsdefinerte objekter, hvor den samordnede tegningen tilveiebringer rutingsinformasjon av flertallet av elementer i prosjektet.

US-publikasjonen beskriver imidlertid ikke en fremgangsmåte for automatisk å generere en tegningsoperasjon av grafiske undersystemer basert på grafiske ressurser som er definert uavhengig av hverandre.

Parametere til tegneoperasjoner i datamaskingrafikkundersystemer er ofte mer enn kun et sett med statiske faste verdier eller datasett. De kan også innbefatte spesialprogrammer som konfigurerer spesifikke eksekveringstrinn i grafikkundersystemet, slik som fragment- eller vertex-shaders i et OpenGL grafikkundersystem. Disse programmene kan så i tur bli konfigurert ved å mate inn tilleggsparametere som er spesifikke for programmet.

Grafikkressurser kan være ufullstendige og må kombineres med andre ressurser for å produsere et meningsfylt og komplett sett med inngangsverdier til et grafikkundersystem. For eksempel trenger en grafikkressurs som beskriver en geometrisk figur i 3D av punkter og trekanter å bli kombinert med et sett med shader-programmer så vel som andre parametere for å bli konvertert til et visuelt bilde ved et OpenGL ES 2.0 grafikkundersystem. Shader-programmene, kommandoer og parametere til OpenGL ES 2.0 grafikkundersystemer må skrives slik at de samsvarer med dataformatene og tilgjengelige attributter i grafikkressursene for å produsere ønsket resultat. I mange tilfeller er det ikke ønskelig å skrive et shader-program for hver grafikkressurs fordi denne prosessen involverer manuelt arbeid. Tidligere kjente metoder og teknikker som adresserer dette problemet innbefatter å skrive spesialprogrammer som kan håndtere et sett med kombinasjoner av inngangsverdier, og konfigurere og pre-prosessere dette programmet før kompilering eller under kjøring basert på egenskaper til grafikkressursen som blir fremstilt (rendered).

Det er ofte ønskelig å uttrykke grafikkressursattributter i form av programmerte funksjoner eller uttrykks grafer som beregner attributtene basert på omgivelsesbetingede inngangsverdier, for eksempel ved å beskrive materialet til et objekt som en funksjon som beregner mengden av lys som den reflekterer gitt en visningsvinkel og belysningsvektorer. Dette blir typisk uttrykt i form av shader-kode, eller i dataformater som tillater at uttrykksgraf er blir tilordnet til attributter. Dette gir flere utfordringer når det er ønskelig å kombinere multiple grafikkressurser til en enkelt tegneoperasjon, for eksempel dersom det er ønskelig å kombinere funksjonen beskrevet over med en annen funksjon som beregner mengden lys reflektert på et objekt fra omgivelsene. De fleste grafikkundersystemer kan kun håndtere ett enkelt shader-program for hvert programmerbare eksekveringstrinn i grafikkproduksjonsbåndet (graphic pipeline). Når multiple programmer eller tilleggsuttrykksgrafer skal anvendes, er kombinering av disse ressursene for å danne et enkelt shader program for hvert programmerbare eksekveringstrinn ikke-trivielt og krever ofte spesialistkompetanse. Det eksisterer flere tidligere kjente teknikker og fremgangsmåter som adresserer problemet, hvor de fleste involverer å sette restriksjoner på måten slike grafikkressurser kan bli representert slik at fremgangsmåten kan kombinere dem sammen til et sett med shader-programmer som prediktivt er gyldige og fungerer sammen.

Videre, når multiple grafikkressurser blir kombinert er ikke nødvendigvis de resulterende kombinerte shader-programmene for hver programmerbare eksekveringssteg optimal. Det kan være redundante operasjoner i de resulterende programmene når grafikkressurser blir kombinert. For eksempel kan en operasjon programmert til å eksekvere i et parallelt eksekveringstrinn, slik som en vertex-shader i OpenGL undersystem, ende opp med inngangsverdier som er konstante for alle prosesserte entiteter. Ytelsen til undersystemet vil sannsynligvis forbedres dersom operasjonen flyttes til et eksekveringstrinn som eksekverer mindre ofte, fortrinnsvis på CPU'en forut for initiering av tegneoperasjonen. Denne endringen er imidlertid ikke-triviell å utføre ettersom den kan kreve endringer i flere deler av software-applikasjonen. Dette problemet blir delvis adressert ved tidligere kjente fremgangsmåter ved å konstruere en kombinert uttrykksgraf fra all tilveiebrakt shader-kode for alle eksekveringstrinn i grafikkundersystemet, og å analysere og modifisere uttrykksgrafen for å flytte redundante operasjoner til de mest optimale eksekveringstrinnene og samtidig beholde korrekt oppførsel for systemet, og så transformere den resulterende uttrykksgrafen tilbake til shader-kode. Dette blir nå ofte utført av softwaredrivere til grafikkundersystemer.

Den foreliggende oppfinnelsen gir forbedringer i forhold til tidligere kjent teknikk ved å introdusere en ny representasjon for grafikkressurser og en fremgangsmåte som automatisk konverterer grafikkressurser i nevnte representasjon til tegneoperasjoner for et passende grafikkundersystem. Oppfinnelsen introduserer også en ny fremgangsmåte for å kombinere slike ressurser på en slik måte at grafikkressurser som er definert uavhengig av hverandre automatisk kan produsere et tilfredsstillende visuelt bilde (image output). Den foreliggende oppfinnelsen tillater grafikkressursrepresentasjon å fange inn informasjon om ønsket fremtoning og oppførsel til ressursen uten å assosiere informasjonen til et spesifikt eksekveringstrinn, programmeringsspråk, grafikk API eller spesifikk grafikkundersystemkarakteristikk. Dermed vil grafikkressurser representert ved å bruke den foreliggende oppfinnelsens representasjon ha forbedret gjenbruksverdi på tvers av grafikkundersystemer og være enkel å kombinere med andre grafikkressurser med redusert behov for manuelt arbeid.

Kort beskrivelse

Den foreliggende oppfinnelsen omfatter en fremgangsmåte for automatisk å generere en tegneoperasjon på ethvert grafikkundersystem basert på grafikkressurser definert uavhengig av hverandre. Fremgangsmåten er definert ved: - å identifisere alle parametere som er nødvendig for nevnte tegneoperasjoner; - å etablere en sortert liste med grafikkegenskaper fra nevnte grafikkressurser; - å utføre, i nevnte sorterte liste med grafikkegenskaper, en spørring etter parametere som er nødvendig for nevnte tegneoperasjon; - å etablere uttrykksgrafer basert på resultatet av nevnte spørring; - å splitte de resulterende uttrykksgrafene i isolerte deler av uttrykksgrafer ved grensen mellom ulike eksekveringstrinn, og - å konvertere hver isolerte uttrykksgraf til konvensjonell kode i et programmeringsspråk som er passende for hvert eksekveringstrinn.

Videre aspekter ved oppfinnelsen er definert i de vedlagte uselvstendige kravene.

Oppfinnelsen er også beskrevet ved et datamaskinprogram som når det er lastet inn og eksekvert på en prosesseringsinnretning omfatter instruksjoner for å utføre fremgangsmåten definert i kravsettet.

Detaljert beskrivelse

Den foreliggende oppfinnelsen vil nå bli beskrevet i detalj med henvisning til tegningene hvor: Figur 1 viser hvordan en grafikkressurs omfatter en sortert liste med egenskaper, hvor hver egenskap har et navn og en liste med definisjoner i prioritetsrekkefølge. Figur 2 viser et eksempel på grafikkressurs som beskriver geometrien til en trekant (Triangle) ved å tilveiebringe en egenskap (Property) kalt "Vertices" og en matrise med 2D-punkter som dens eneste definisjon. Figur 3 viser et eksempel på grafikkressurs som beskriver hvordan OpenGL-spesifikke tegneoperasjonsparametere kan trekkes ut fra mer abstrakte egenskaper for å oppnå en spesifikk visuell effekt. Figur 4 viser hvordan to eksempelvise grafikkressurser kan bli kombinert til en ny ressurs (Combined Graphic Asset)ved å sammenkjede (concatenating) listen med egenskaper til en ny liste med egenskaper. Figur 5 viser en eksempelsekvens med undersøkelser (examinations) og operasjoner

utført på en grafikkressurs for en egenskap med et visst navn.

Figur 6 viser et eksempel på en resulterende uttrykksgraf for et OpenGL

grafikkundersystem etter spørring av en grafikkressurs etter parameterne "glFragColor" og "gl_Position".

Figur 7 viser en modifisert versjon av Figur 6, hvor uttrykksgrafen har blitt splittet i to isolerte grafer for vertex og fragmenteksekveringstrinn, og en spesialnode "varying interpolation" har blitt innført ved grensen mellom to eksekveringstrinn.

Formålet med den foreliggende oppfinnelsen er automatisk å generere tegneoperasjoner på ethvert grafikkundersystem basert på grafikkressurser som er definert uavhengig av hverandre. I henhold til oppfinnelsen tillater måten som ressurser blir representert på å håndtere ukomplette ressurser via en kombinasjon av reserveløsning (fall back) og standard (default) verdier for egenskapene.

For eksempel kan oppfinnelsen bli brukt til å generere sanntid interaktiv rendering av en 3D modell tilveiebrakt i COLLADA filformat, ved å generere et program som gir tegneoperasjoner til et OpenGL ES 2.0 grafikkundersystem og shader-programmer for ulike eksekveringstrinn til undersystemene.

Eksempelet kan utvides ved at data fra COLLADA filen blir kombinert med ressurser definert separat som definerer et sett med koblinger (mappings) mellom COLLADA egenskapene og den ønskede belysningsmodellen, og ressurser som definerer felles visnings- og projeksjonstransformasjoner. Dersom COLLADA-dataene ikke inneholder alle egenskapene som er nødvendig for å beregne alle parameterne til en tegneoperasjon kan andre ressurser i kombinasjonen definere standard [default] verdier eller reserveløsningsdefinisjoner for egenskapene som ikke krever at disse verdiene er tilstede for å produsere et meningsfylt resultat. Dette fjerner behovet for manuelt spesialistarbeid for å løse slike tilfeller.

I et annet eksempel kan oppfinnelsen bli brukt for å kombinere multiple formater for å beregne uavhengige komponenter til en belysningsmodell til et felles sett med shader programmer, med 3D modeller som er definert som matematiske funksjoner, og så gi ut tegneoperasjoner til et ikke-sanntids strålesporings (ray-tracing) grafikkundersystem for filmaktige (cinematic) bilder basert på kombinasjonen av ressurser.

Figur 1 viser strukturen til en grafikkressurs (Graphic Asset). En grafikkressurs omfatter en sortert liste med egenskaper (Property). Hver egenskap har et navn (Name) som identifiserer semantikkbetydningen til egenskapen. Navnet er ikke nødvendigvis unikt innen ressursen siden det kan være multiple egenskaper med samme semantikknavn. I tillegg til et navn har hver egenskap en sortert liste med null eller flere definisjoner (Definition 1, Definition 2, ...), definert prioritetsrekkefølge. Hver definisjon omfatter en uttrykksgraf med operatorer (noder) og kanter som uttrykker en måte som verdien til egenskapen kan bli beregnet på.

Fremgangsmåten i henhold til den foreliggende oppfinnelsen blir anvendt ved først å identifisere alle parameterne som er nødvendig for type tegneoperasjon som en søker å generere. Nevnte sett med parametere vil bli referert til som et sett med terminalegenskaper. Settet med terminalegenskaper kan variere betraktelig mellom ulike typer av grafikkundersystemer og implementering av den foreliggende oppfinnelsen.

For eksempel kan en i en implementering av den foreliggende oppfinnelsen for OpenGL ES 2.0 grafikkundersystemet, velge å innbefatte de følgende parameterne i settet med terminalegenskaper: • standardutgangsverdiene fra vertex- og fragment-shader trinnene

("gl Position" and "gl FragColor", respektivt)

• de fleste gjengivelses- (render) tilstander i OpenGL ES 2.0 tilstandsmaskinen (dvs. for eksempel om blanding (blending) er aktivert, hvilken blandefunksjon som skal brukes, hvilken linjebredde som skal brukes)

Hver egenskap i settet med terminalegenskaper bør bli tilegnet et navn som kan brukes av grafikkressurser for å tilegne verdier til de underliggende parameterne i tegneoperasjonen.

Merk at egenskapene i terminalsettet ikke nødvendigvis er mulig å redusere til faste verdier på forhånd fordi de kun gir mening i visse eksekveringstrinn, slik som inne in en vertex eller fragment shader. Egenskapene i terminalsettet kan kun bli uttrykt som uttrykksgrafer, eller programkode, og kan kun bli evaluert til faste verdier i en kontekst under kjøring.

Etter at settet med parametere til tegneoperasjonen har blitt identifisert, blir en sortert liste med grafikkegenskaper etablert. I det enkleste tilfellet blir dette gjort ved å ta den sorterte listen med grafikkegenskaper fra en enkelt grafikkressurs. Videre blir, for hver parameter til tegneoperasjonen, en spørring utført på nevnte sorterte liste med grafikkegenskaper for å bestemme en gyldig definisjon for navnet til parameteren. En spørring blir vanligvis utført som følgende: 1. Start med den siste egenskapen i den sorterte listen med grafikkegenskaper, sammenlikne navnet til egenskapen med grafikkressursen med det samme navnet som det blir utført spørring på og fortsetter bakover i listen inntil et motstykke (match) blir funnet. Dersom ikke et motstykke blir funnet så feiler spørringen. En feilende spørring betyr at det ikke er nok informasjon i ressursen(e) til å generere en meningsfull tegneoperasjon. 2. Når et motstykke blir funnet, så undersøkes definisjonene til motstykkeegenskapen i prioritetsrekkefølge og returnere den første gyldige definisjonen. Dersom ingen gyldig definisjon finnes så feiler spørringen. Å bestemme kriteriet for om en definisjon er gyldig er opp til implementeringen. For eksempel kan et kriterium for gyldighet være om uttrykksgrafen til en definisjon inneholder operatorer som ikke er tilgjengelige på målgrafikkundersystemet.

Dersom alle spørringene er vellykket, kan resultatet sees som et sett med rotnoder med potensielt sammennøstede uttrykksgrafer. Hver egenskap i terminal-egenskapssettet vil være assosiert med nøyaktig en rotnode i nevnte grafer.

Figur 6 viser et eksempel på en slik sammenfiltret uttrykksgraf som resulterer fra spørringen "gl FragColor" og "gl Position", som er egenskapene i et terminalsett.

Det neste trinnet er å traversere den sammenfiltrede uttrykksgrafen for å splitte den inn i isolerte undergrafer for hvert eksekveringstrinn i grafikkundersystemet. Nøyaktig hvordan nevnte splitting blir utført avhenger av implementering, og er i store trekk definert ved egenskapen til forholdet mellom eksekveringstrinnene til grafikkundersystemet. Implementeringen av denne oppfinnelsen kan introdusere ytterligere kunstige eksekveringstrinn, for eksempel eksekveringstrinn som omfatter kode som eksekverer en gang per fremstilte bilde, nå og da i tidsenheter eller i respons på eksterne programavbrudd (interrupts).

For at algoritmen for å splitte opp grafen skal være triviell, må eksekveringstrinnene til implementeringen ha en definert rekkefølge, fra "først" til "sist". Hvordan rekkefølgen defineres er avhengig av grafikkundersystem og implementeringsdetaljer. Som en retningslinje går imidlertid eksekveringstrinn "A" foran eksekveringstrinn "B" dersom operatorer i trinn "B" kan lese verdier fra trinn "A" som om de er konstante i den relevante varigheten med eksekvering av kode i trinn "B". For eksempel går vertex-shader trinnet i OpenGL ES 2.0 grafikkundersystemet foran fragment-shader trinnet fordi fragment-shader trinnet kan lese verdier fra vertex-shader trinnet som interpolerte konstanter. Likeledes går et per-fremstil-bilde (a per visual frame) eksekveringstrinn foran vertex-shader trinnet i OpenGL ES 2.0 grafikkundersystemer fordi vertex-shadere kan lese verdier fra CPlTen gjennom verdier som er konstante for alle tråder av en shader (uniforms). Dersom ikke eksekveringstrinnet har en veldefinert rekkefølge, så må implementeringsspesifikke regler bestemme kriteria og fremgangsmåte for nevnte splitting av uttrykksgrafer til isolerte undergrafer for hvert eksekverings-trinn.

Som et eksempel på hvordan en slik uttrykksgrafsplittingsfremgangsmåte kan oppføre seg er det naturlig å starte med en terminalegenskap til det "siste" eksekveringstrinnet, slik som utgangsverdiene til fragment-shader trinnet i OpenGL ES 2.0 grafikkundersystemer. Vi traverserer så uttrykksgrafen, og fargelegger operatorer som er nødvendig for å eksekveres på et spesifikt trinn (eller "senere"). For en operator som ikke er bundet til et spesifikt trinn, så tilegner vi rekursivt det "siste" eksekveringstrinnet til dens inngangsnoder som er brukt som eksekveringstrinn for nevnte operator.

Figur 7, sett i relasjon til Figur 6, illustrerer hvordan en uttrykksgraf kan bli splittet. I dette eksempelet er en "varying interpolation" node innført ved kanter som separerer fragment-shader eksekveringstrinnet fra vertex-shader eksekveringstrinnet. Slike kantnoder vil eksistere i begge undergrafer og skal senere oversettes til mekanismen i undersystemet som viderefører verdier fra ett trinn til et annet.

Når uttrykksgrafen har blitt splittet inn i isolerte undergrafer for hvert eksekveringstrinn, kan den resulterende grafen bli konvertert til konvensjonell programkode, enten ved å generere maskinkode direkte, eller gi ut kildekode i et konvensjonelt programmeringsspråk. Dette er vurdert å være trivielt og er dekket av fremgangsmåter i tidligere kjent teknikk.

Kjernen i den foreliggende oppfinnelsen omfatter en innretning eller datamaskinprogram som implementerer fremgangsmåten som er diskutert over. Vi vil nå utdype utvidelser til denne fremgangsmåten som videre forbedrer den tekniske funksjonen og applikasjonen til den foreliggende oppfinnelsen.

Ved å vende tilbake til Figur 1 husker vi at en grafikkressurs omfatter en sortert liste med egenskaper. Vi utvider oppfinnelsen ved å introdusere en fremgangsmåte for å kombinere grafikkressurser definert uavhengig av hverandre til en ny grafikkressurs ved å sammenkjede deres respektive lister med grafikkegenskaper.

Figur 4 viser hvordan to ressurser som er definert uavhengig av hverandre blir kombinert ved å sammenkjede de respektive listene med egenskaper.

Logikken bak fremgangsmåten med å kombinere ressurser er antakelsen om at listen er sortert slik at den første listede egenskapen er den mest generelle og de etterfølgende egenskapene er mer spesifikke. Når multiple grafikkresurser blir kombinert bør resursene bli sortert på den samme måten. Den mest generelle ressursen bør bli satt i rekkefølge først, og ressurser med avtagende generalitet og økende spesialisering bør etterfølge, slik at når listene med egenskaper er sammenkjedet, vil i størst mulig grad antakelsen om at egenskapene er sortert etter generalitet gjelde også for den resulterende sammenkjedede listen. Det å definere hva som er mer generelt i denne konteksten og rekkefølgen av sammenkjeding er opp til implementeringen og sluttbruker.

Som et eksempel, dersom en kombinerer ressursene illustrert i Figur 2 og 3, vil det være foretrukket å sette de opp i rekkefølgen [Shading2D, Triangle], siden Shading2D ressursen inneholder generelle forhold mellom terminalegenskaper og abstrakte egenskaper som er antatt å være brukbare for multiple ressurser, mens en trekant kan i sammenlikning antas å være en mer spesifikk ressurs.

En vil typisk kombinere et antall grafikkressurser til en større grafikkressurs forut for etablering av en endelig sortert liste med grafikkressurser fra hvilken en genererer en tegneoperasjon. Settet med grafikkressurser som skal kombineres bør velges basert på kombinasjonen av geometriske objekter som en ønsker å visualisere, de visuelle effektene som en ønsker å anvende på objektet, omgivelsebetingede faktorer som skal påvirke objektet, det grafikkundersystemet som er målet, og flere andre vurderinger, slik som sanntid gjengivelsesytelse (rendering performance).

Som en implementeringsretningslinje bør spesifikke grafikkressurser fortrinnsvis ikke definere egenskaper som tilegner verdier direkte til grafikkundersystemspesifikke terminalegenskaper. I stedet bør grafikkressurser som tilegner verdier til mer generelle semantiske egenskaper, og separate grafikkressurser som er generelle for et grafikkundersystem definere egenskaper som tilordner generelle semantiske egenskaper tilbake til grafikkundersystemspesifikke terminalegenskaper.

Den ovenfor beskrevne retningslinjen er eksemplifisert med forholdet mellom Figur 2 og Figur 3. Figur 2 viser grafikkressursen "Triangle", som i stedet for å definere nøyaktig hvordan terminalegenskapen "glPosition" blir beregnet kun tilveiebringer den mer generelle egenskapen "Vertices", som andre ressurser kan bruke for å beregne andre nyttige verdier når disse kombineres med Triangle-ressursen. Figur 3 viser en separat grafikkressurs som definerer hvordan terminalegenskapene "gl Position" and "glFragColor" kan bli beregnet, dersom det finnes mer generelle egenskaper slik som "Vertices" eller "Colors".

Oppfinnelsen er videre utvidet til å dekke fremgangsmåter hvor spesielle programmeringsspråkkonstruksjoner (constructs) eller datastrukturer blir introdusert for implisitt å definere rekkefølgen for å kombinere grafikkressurser ved forbindelsene til nevnte språkkonstruksjoner eller datastrukturer til andre språkkonstruksjoner eller datastrukturer.

Som et eksempel kan en objektorientert programmeringsspråkkompilator som implementerer denne oppfinnelsen definere at felt og egenskaper til en klasse eller datastruktur implisitt opptrer som grafikkegenskaper ved anvendelse av den foreliggende oppfinnelsen, og at klasser eller datastrukturer dermed kan i seg selv bli sett på som grafikkressurser.

I en utvidelse av eksempelet kan et objekt orientert programmeringsspråkkompilator som implementerer denne oppfinnelsen definere at dersom klasse "B" arver en annen klasse "A", og "A" og "B" sees på som grafikkressurser, så vil listen med grafikkegenskaper som er assosiert med klasse "A" bli sammenkjedet til en liste med grafikkegenskaper assosiert med klasse "B" i rekkefølgen [A, B] ved anvendelse av den foreliggende fremgangsmåten. Siden baseklasser blir betraktet som mer generelle enn underklasser er dette konsistent med implementeringsretningslinjen om at mer generelle grafikkegenskaper skal gå foran mer spesifikke grafikkegenskaper.

I en videre utvidelse av eksempelet kan en shader-språkkompilator eller prosessor definere at vertex attributter, uniformer, varyings og globale variabler implisitt blir betraktet som grafikkegenskaper ved anvendelse av den foreliggende oppfinnelsen, og dermed kan en shader i sin helhet betraktes som en grafikkressurs.

I en videre utvidelse av eksempelet kan et programmeringsspråk introdusere spesielle språkkonstruksjoner eller datastrukturer for å definere et hierarki med grafer eller blokker med grafikkegenskaper, innbefattende spesialblokker som representerer en "tegnebar" ressurs så vel som "ikke-tegnebare" ressurser. En "ikke-tegnebar" ressurs kan for eksempel være en node i et hierarki med animerte forbindelser/ledd (joints) uten noen faktisk visuell representasjon unntatt en indirekte eller betinget påvirkning på den visuelle representasjonen av andre ressurser. Et annet eksempel på en "ikke-tegnebar" ressurs er en lyskilde uten noen visuell representasjon bortsett fra lyset som den kaster på andre objekter. I tillegg kan spesialblokker bli introdusert hvor disse blir konvertert til faktiske subrutiner som vil inneholde tegneoperasjoner generert ved å anvende den foreliggende fremgangsmåten på alle "tegnebare" grafikkressurser i gitt skop eller sti (scope or path) i kombinasjon med alle andre grafikkressurser i en sortert liste som er definert ved å traversere hierarkiet eller grafen ved å bruke en gitt tilfeldig framgangsmåte.

I en videre utvidelse av eksempelet kan et datamaskinprogram som kan lese og tolke data fra konvensjonelle datamaskingrafikkressursformater, slik som COLLADA eller CAD filer, definere en kobling fra nevnte ressursformat til grafikkegenskaper, ved anvendelse av den foreliggende oppfinnelsen, og data i et slikt format kan dermed bli betraktet som grafikkressurser. I tillegg kan nevnte datamaskinprogrammer definere koblinger fra slike formater til spesielle språkkonstruksjoner eller datakonstruksjoner som omfatter hierarkier eller grafer med blokker med grafikkegenskaper, som beskrevet over.

Ved videre å utvide eksempelet kan et programmeringsspråk, innholds-utviklingsverktøy (authoring tool), datamaskinprogram eller en annen innretning som implementerer oppfinnelsen tillate at spesielle språkkonstruksjoner eller datakonstruksjoner blir manipulert enten som tekst, rådata eller reflektert i en brukergrensesnittkontroll, for å muliggjøre at en bruker eller agent definerer kombinasjonsrekkefølgen til enhver av nevnte grafikkressurstyper, så vel som rekkefølge ved traversering av hierarkier og grafer med blokker med grafikkegenskaper, for å produsere nye grafikkressurser eller tegneoperasjoner.

Når en vender tilbake til Figur 1 husker vi at en grafikkegenskap i sin enkleste form har nøyaktig én definisjon. Vi vil nå diskutere hvordan en grafikkegenskap kan bli utvidet til å ha et flertall definisjoner i en definert prioritetsrekkefølge.

Denne utvidelsen tillater at egenskaper blir definert med reserveløsninger (fallbacks) for å bedre håndtere ufullstendige datasett i kombinerte ressurser, og generelt øke robustheten til fremgangsmåten og redusere sjansen for at spørringer feiler. Definisjonene til en egenskap er typisk sortert etter prioritet, slik at den første definisjonen inneholder en uttrykksgraf som betegner den mest ønskelige måten for å beregne verdien til en egenskap, mens etterfølgende definisjoner representerer mindre ønskelige men akseptable måter for å beregne verdien til egenskapen.

I Figur 3, inneholder egenskapen "glFragColor" to definisjoner med en definert prioritetsrekkefølge fra venstre til høyre. Som første prioritet er "glFragColor" definert for å anvende "vertex atrib" operator til egenskap med navn "Vertices". Dersom dette blir bestemt å være ugyldig ved implementering blir imidlertid fastverdien "Red" tilveiebrakt som en reserveløsningsdefinisjon for egenskapen.

Den ovenfor nevnte utvidelsen har konsekvenser for fremgangsmåten som blir brukt for å utføre spørringer på grafikkressurser. Den tidligere beskrevne fremgangsmåten hvor en spørring blir utført ved å undersøke listen med grafikkegenskaper ved å starte med den sist listede grafikkegenskapen og fortsette i reversert rekkefølge inntil den første matchende grafikkegenskapen blir funnet, blir nå utvidet ved deretter å undersøke definisjonene til den matchede grafikkegenskapen i prioritetsrekkefølge og returnere den første gyldige definisjonen.

Den ovenfor nevnte fremgangsmåten blir videre utvidet til å dekke fremgangsmåter hvor gyldigheten til en definisjon blir bestemt ved å evaluere et gitt sett med predikater for hver definisjon. I denne konteksten skal predikater forstås å være funksjoner eller uttrykksgrafer som evaluerer til en boolsk verdi (true or false), som betegner om definisjonen er gyldig eller ikke. Predikatene kan bli assosiert til egenskaps definisjoner som en del av grafikkressursdatastrukturen. Predikat-uttrykksgrafer kan, på en linkende måte som definisjonene selv, ha noder som refererer til andre grafikkegenskaper og anrope rekursive spørringer på listen med grafikkegenskaper for å beregne nevnte boolske verdi. Oppfinnelsen blir også utvidet til å dekke fremgangsmåter som, dersom en predikat ikke kan bli evaluert til fast verdi ved anvendelse av oppfinnelsen, sender ut programkode som evaluerer predikatet ved et senere tidspunkt, og en forgrening til kode for å håndtere begge stiene ved kjøring (hvor definisjonen enten er gyldig eller ugyldig) blir generert.

Oppfinnelsen er videre utvidet til å dekke fremgangsmåter hvor dersom definisjonen returnert av en spørring etter et grafikkegenskapsnavn inneholder en referanse til en annen grafikkegenskap da utfører en ny spørring etter den refererte grafikkegenskapen utført rekursivt.

Figur 5 illustrer en eksempelvis eksekvering av en spørring (Query) ved å bruke multiple definisjoner som reserveløsninger, så vel som egenskaper som inneholder referanser til andre egenskaper som anroper rekursive spørringer.

Den følgende utdypningen forklarer de nummererte pilene i figuren sekvensielt. Vi starter med (1) som spesifiserer navnet til egenskapen som det blir utført spørring etter, i dette tilfellet "A". (2) Vi undersøker den siste egenskapen i listen, i dette tilfellet egenskap 4 med navnet "A". Siden denne har navn tilsvarende den egenskapen som det blir utført en spørring etter undersøker (3) vi den første definisjonen til egenskapen. Ved å anta at "x" ikke er en gyldig definisjon fortsetter (4) vi å undersøke den andre prioritetsdefinisjonen til den tilsvarende egenskapen. Denne inneholder uttrykket "Prev(A)", som et eksempel på hvordan en definisjon rekursivt kan anrope spørringer. "Prev" er her antatt å være en operator som refererer til en tidligere definisjon til egenskapsnavnet (property name) tilveiebrakt som argument. Dette løses ved å anrope en spesiell type spørring som i stedet for å starte fra den den sist listede grafikkegenskapen starter ved grafikkegenskapen som går forut for den for tiden tilsvarende egenskapen. Dette betyr (5) å undersøke den tredje egenskapen i listen, og denne gangen se etter en tilsvarende med egenskapsnavnet "A" tatt fra argumentet til operatoren "Prev". Vi fortsetter bakover gjennom (6) egenskap 2 og, vi finner tilslutt (7) en tilsvarende med navnet "A" med egenskap 1.

Vi undersøker dens definisjoner i prioritetsrekkefølge ved å starte med (8) "x", som fremdeles antas å være ugyldig. Vi fortsetter til (9) som er en henvisning til en egenskap med navn "B". Dette er en regelmessig referanseegenskap som involverer en ny spørring ved å starte fra (10) den siste listede grafikkegenskapen, fortsetter bakover gjennom (11) egenskap 3, og tilslutt samsvar med (12) egenskap 2. Vi undersøker de samsvarende egenskapenes definisjoner i prioritetsrekkefølge. Ved å anta (13) at "z" er en gyldig definisjon, blir så "z" returnert som det endelige resultatet av spørringen.

Som allerede reflektert i diskusjonen så langt kan oppfinnelsen håndtere scenarioer hvor de eksisterende uttrykks grafene fra spørringen av en liste med grafikkressurser for tegneoperasjonsparametere inneholder operatorer som er linket til spesifikke eksekveringstrinn.

Slike operatorer er for eksempel tekstur-utlesinger (texture samples) i et OpenGL ES 2.0 grafikkundersystem, som i noen implementeringer er mulig i fragmentshaderen, så vel som på CPU'en, men ikke i vertexshaderen.

En mulig fremgangsmåte for å adressere dette er allerede presentert, hvor en slik node ville blitt fargelagt for å måtte eksekveres i et spesielt trinn og en rekursiv fargeleggingsfunksjon ville tvinge noder avhengig av output fra den noden til å eksekvere i det samme trinnet eller "senere".

Vi vil skissere et utkast til en alternativ fremgangsmåte for å adressere et mer komplekst scenario, som et eksempel på en klasse med fremgangsmåter som kan utvide denne oppfinnelsen.

Dersom for eksempel en operator er krevd for å bli eksekvert på vertekstrinnet, men grafikkundersystemet ikke tillater den operatoren i GPU vertexshaderen, kan en lage et kunstig verteksprosesseringstrinn som eksekverer på CPU'en i tillegg til GPU vertexshaderen, og anvende en transformasjon på uttrykks grafene som flytter en slik operator til nevnte kunstige eksekveringstrinn, og tilsvarende flytter kantoperatorene som mater de resulterende vertexstrømmene inn i GPU vertexshaderen. Dette vil effektivt produsere et program med en delvis reserveløsning (fall back) til CPU vertexprosessering.

Den oppfinneriske fremgangsmåten kan bli utført av et datamaskinprogram som omfatter instruksjoner for å utføre den oppfinneriske metoden når datamaskinprogrammet er lastet inn og eksekvert på en prosesseringsinnretning.

For en fagperson på området vil det være opplagt at den oppfinneriske fremgangsmåten som er beskrevet med henvisning til tegneoperasjoner på ethvert grafikk API også kan bli beskrevet mer generelt. Det kan f.eks. bli implementert som en utvidelse til ethvert passende eksisterende programmeringsspråk og kompilator.

Claims (8)

1. Fremgangsmåte for automatisk å generere en tegneoperasjon på ethvert grafikkundersystem basert på grafikkressurser definert uavhengig av hverandre,karakterisert ved: a. å identifisere alle parametere som er nødvendig for nevnte tegneoperasjoner; b. å etablere en sortert liste med grafikkegenskaper fra nevnte grafikkressurser; c. å utføre en spørring, i nevnte sorterte liste med grafikkegenskaper, etter parametere som er nødvendig for nevnte tegneoperasjon; d. å etablere uttrykksgrafer basert på resultatet av nevnte spørring; e. å splitte de resulterende uttrykksgrafene i isolerte deler av uttrykksgrafer ved grensen av ulike eksekveringstrinn, og f. å konvertere hver isolerte uttrykksgraf til konvensjonell kode i et programmeringsspråk som er passende for hvert eksekveringstrinn.

2. Fremgangsmåte i henhold til krav 1, hvor den sorterte listen blir etablert ved å kombinere grafikkressurser definert uavhengig av hverandre til en ny grafikkressurs ved å sammenkjede deres respektive lister med egenskaper.

3. Fremgangsmåte i henhold til krav 2, hvor rekkefølgen av de kombinerte grafikkressursene blir definert ved hjelp av spesielle programspråkressurskonstruksjoner eller datastrukturer og deres relasjon.

4. Fremgangsmåte i henhold til krav 1, hvor en eller flere grafikkegenskaper blir utvidet til å ha multiple definisjoner i en definert prioritetsrekkefølge.

5. Fremgangsmåte i henhold til krav 1 eller 4, hvor spørringen blir utført ved å undersøke listen med grafikkegenskaper og starte med den sist listede grafikkegenskapen og fortsette i motsatt rekkefølge inntil en matchende grafikkegenskap blir funnet.

6. Fremgangsmåte i henhold til krav 5, hvor gyldigheten til en definisjon blir bestemt ved å evaluere et gitt sett med predikater for hver definisjon.

7. Fremgangsmåte i henhold til krav 5, hvor dersom resultatet av en spørring om en grafikkegenskap inneholder en referanse til en annen grafikkegenskap, så vil en ny spørring i henhold til krav 5 bli utført rekursivt for den refererte grafikkegenskapen.

8. Datamaskinprogram som når det er lastet inn og eksekvert på en prosesseringsinnretning omfatter instruksjoner for å utføre fremgangsmåten i henhold til ett eller flere av fremgangsmåtekravene 1 til 7.