mboost-dp1

Nvidia
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
CUDA er programmering af de mange Unified Shaders som de nye kort har og kan ikke rigtig sammenlignes med DirectX og OpenGL som er abstrakte API'er til alle funktioner som kortet understøtter...
CUDA er en avanceret udgave af HLSL (High Level Shader Language) som er en DirectX version af Shader programmering.
AMD har deres egen variant kaldet AMD APP og Microsoft kalder det DirectCompute - men er i modsætning til Nvidia og AMD, cross platform ligesom OpenCL.
CUDA er en avanceret udgave af HLSL (High Level Shader Language) som er en DirectX version af Shader programmering.
AMD har deres egen variant kaldet AMD APP og Microsoft kalder det DirectCompute - men er i modsætning til Nvidia og AMD, cross platform ligesom OpenCL.
Vil gerne lige rette lidt på mig selv:
CUDA og HLSL er to forskellige sprog og det ene bygger ikke på det andet. Det jeg mente var at CUDA ligesom HLSL, er Shader programmering. Hvor CUDA bare er mere avanceret og nemmere at skrive.
CUDA og HLSL er to forskellige sprog og det ene bygger ikke på det andet. Det jeg mente var at CUDA ligesom HLSL, er Shader programmering. Hvor CUDA bare er mere avanceret og nemmere at skrive.
Montago.NET (1) skrev:CUDA er programmering af de mange Unified Shaders som de nye kort har og kan ikke rigtig sammenlignes med DirectX og OpenGL som er abstrakte API'er til alle funktioner som kortet understøtter...
CUDA er en avanceret udgave af HLSL (High Level Shader Language) som er en DirectX version af Shader programmering.
AMD har deres egen variant kaldet AMD APP og Microsoft kalder det DirectCompute - men er i modsætning til Nvidia og AMD, cross platform ligesom OpenCL.
Det vil sige at OpenCL virker på både AMD og NVIDIA kort og både på Linux, OSX og Windows m.fl. ?
Hvis AMD APP og CUDA har nogle funktioner som er tilstrækkelige ens så kunne Microsoft måske med held tilføje et fælles API lag til deres OpenCL sådan at AMD APP funktioner og/eller CUDA funktioner kunne kaldes med fælles interface sammen med eventuelle relevante OpenCL funktioner.
Alternativt skulle der måske startes et joint API projekt sådan at udviklere ikke skal tage hensyn til to eller tre seperate shader systemer.
CBM (3) skrev:Alternativt skulle der måske startes et joint API projekt sådan at udviklere ikke skal tage hensyn til to eller tre seperate shader systemer.
Er det ikke det der er formålet med OpenCL? At lave en åben standard.
Der vil nok også snart opstå et behov for decideret multi-tasking på GPU'en, for p.t. er det sådan, at når man kører noget tungt på CUDA, så hakker og sprutter éns system fordi GPU'en jo får travlt. - F.eks. hvis Blender står og renderer.
Hvis der så var et multitasking OS på grafikkortet, ville man kunne prioritere her-og-nu opgaver (som optegning af vinduer) højere end ting som godt kan vente et par millisekunder (f.eks. rendering af 3D.)
Hvis der så var et multitasking OS på grafikkortet, ville man kunne prioritere her-og-nu opgaver (som optegning af vinduer) højere end ting som godt kan vente et par millisekunder (f.eks. rendering af 3D.)
BetaLyte (7) skrev:#5
Det vil jo kræve MIMD kerner på kortet, hvilket vil modvirke idéen med at en GPU er SIMD.
Hvorfor?
Du kan have multitasking CPU som ikke er MIMD. Hvorfor så ikke en multitasking GPU uden MIMD?
Altså jeg tror heller ikke på ideen, men jeg forstår ikke argumentet.
#10
Jeg går ud fra du hentyder til time-slicing / sharing? Det vil jo heller ikke rigtig give mening på en GPU, der er udviklet til at foretage komplekse udregninger hurtigst muligt.
Der foregår dog sikkert noget time-slicing på consumer GPU'er alligevel, for at sikre at GUI'en er responsiv, men det giver jo ikke rigtig mening på systemer dedikerede til den slags store udregninger.
Alternativt, så kunne man måske overlade opdatering af skærmen til CPU'en, mens GPU'en gjorde sit arbejde?
Jeg går ud fra du hentyder til time-slicing / sharing? Det vil jo heller ikke rigtig give mening på en GPU, der er udviklet til at foretage komplekse udregninger hurtigst muligt.
Der foregår dog sikkert noget time-slicing på consumer GPU'er alligevel, for at sikre at GUI'en er responsiv, men det giver jo ikke rigtig mening på systemer dedikerede til den slags store udregninger.
Alternativt, så kunne man måske overlade opdatering af skærmen til CPU'en, mens GPU'en gjorde sit arbejde?
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.