Cum se rezolvă problema cu opengl. Ce plăci video acceptă OpenGL?

Dacă primiți un mesaj de eroare la lansarea Movavi Video Editor sau observați că playerul, filtrele sau tranzițiile nu funcționează, atunci computerul dvs. cel mai probabil nu acceptă versiunea de OpenGL necesară pentru ca acesta să funcționeze. Pentru ca programul să funcționeze, placa video trebuie să accepte OpenGL 2.0. Pentru funcționare neîntreruptă Se recomandă OpenGL 2.1 și o versiune ulterioară.

OpenGL Acest interfata software, responsabil pentru ieșirea datelor grafice. De obicei este asigurat de driverul plăcii video. Cu toate acestea, unele plăci video nu acceptă versiunea necesară OpenGL. În acest caz, urmați acești pași:

Pasul 1: Actualizați driverul plăcii grafice

Această problemă poate apărea dacă driverul plăcii video a computerului este învechit. Descărcați fișierul de instalare a driverului de pe site-ul web al producătorului și urmați instrucțiunile de instalare.

Pasul 2: Încercați să instalați implementare software OpenGL

Dacă după actualizarea driverelor placa video încă nu acceptă 2.0, puteți instala un înlocuitor în video software:

În mesajul care apare când lansați Movavi Video Editor, bifați caseta de selectare „Descărcați și instalați implementarea software a OpenGL”.

Sau, în meniul principal al programului, faceți clic pe Setări iar în meniul care apare, selectați Opțiuni. În fereastra de setări, bifați caseta Utilizați implementarea software a OpenGLși apăsați Bine.

Editor video Movavi.

Există atât acceleratoare profesionale, cât și „amatori”...

Tehnologia OpenGL este „doar” un set de specificații pentru instrumentele de procesare grafica pe computer. Folosind OpenGL, dezvoltatorii au o mulțime de posibilități suplimentare, mai ales în ceea ce privește 3D. Mai mult, dacă o platformă sau o placă video nu acceptă toate capacitățile grafice pe care, de exemplu, dezvoltatorul le presupune joc pe calculator, OpenGL este cel care atenuează toate aceste deficiențe prin sprijinirea unei biblioteci de funcții suplimentare.

La începutul anilor 90, producătorii de software trebuiau să se asigure că aplicațiile lor puteau rula cât mai bine posibil. Mai mult plăci video Cu toate acestea, nu exista o specificație unică la acel moment și trebuiau scrise bucăți uriașe de cod pentru ca programul să funcționeze pe hardware diferit. O asemenea indignare nu putea dura mult timp. Și toate problemele de compatibilitate la nivel scăzut au fost rezolvate de OpenGL.

De atunci, programatorii au fost nevoiți să scrie pentru OpenGL, iar producătorii de plăci video trebuie să includă suport pentru această tehnologie în dispozitivele lor. Iată doar câteva dintre zonele în care este utilizat OpenGL:

• modelare tridimensională computerizată a proceselor fizice;
• animatie pe calculator;
• modelare tridimensională în design și publicitate;
• efecte speciale cinematografice;
• și, bineînțeles, grafică pe computer pentru jocuri.

Acceleratoare OpenGL

Numărul total de modificări ale acceleratoarelor OpenGL este probabil imposibil de numărat cu exactitate. Există atât acceleratoare profesionale, cât și „amatori”. Cu toate acestea, utilizatorul mediu nu trebuie neapărat să aprofundeze în toate detaliile tehnice. Tot ce trebuie să știe este dacă placa lui video acceptă tehnologia OpenGL.

Astăzi putem spune cu încredere că orice modern placa video de jocuri, chiar și unul de buget precum nvidia geforce gt 210 acceptă majoritatea specificațiilor OpenGL. Desigur, doar producătorul plăcii video însuși poate oferi un raport complet privind suportul sau nesuportarea tuturor specificațiilor. Prin urmare, testarea acceleratoarelor profesionale OpenGL poate fi lăsată în siguranță profesioniștilor.

Cu toate acestea, situația este complicată de faptul că astăzi există mai multe versiuni de OpenGL. Și dacă, de exemplu, OpenGL 2.0 este procesat cu succes de placa video nvidia geforce gt 210, și majoritatea celorlalți, apoi cu OpenGL 3.0 și cu atât mai mult cu cel mai recent OpenGL 4.5 - doar anumite modele. Și fiecare versiune nouă oferă dezvoltatori de grafică caracteristici suplimentare pentru „desen” și deschide noi lumi computerizate mai realiste pentru utilizator.

Specificațiile complete trebuie vizualizate fie pe site-urile web ale producătorilor de plăci video, fie în documentație. Alegere mare plăci video discrete poate fi găsit pe site

Uneori, opengl32.dll și alte erori erori de sistem DLL-urile pot fi legate de probleme din registrul Windows. Mai multe programe pot folosi fișierul opengl32.dll, dar atunci când aceste programe sunt eliminate sau modificate, uneori rămân intrări „orfane” (eronate) DLL de registru.

Practic, aceasta înseamnă că, deși calea reală a fișierului s-ar putea să se fi schimbat, locația anterioară incorectă a acestuia este încă înregistrată în Registrul Windows. Când Windows încearcă să caute aceste referințe de fișiere incorecte (locațiile fișierelor pe computerul dvs.), pot apărea erori opengl32.dll. În plus, este posibil ca o infecție malware să fi corupt intrările de registry asociate cu FineReader OCR. Astfel, aceste intrări de registry DLL corupte trebuie remediate pentru a remedia problema la rădăcină.

Editarea manuală a registrului Windows pentru a elimina cheile opengl32.dll nevalide nu este recomandată, decât dacă sunteți un profesionist de servicii PC. Greșelile făcute la editarea registrului vă pot face computerul inoperabil și pot cauza daune ireparabile sistemului dumneavoastră de operare. De fapt, chiar și o virgulă plasată în locul greșit poate împiedica pornirea computerului!

Din cauza acestui risc, vă recomandăm cu căldură să utilizați un program de curățare de registru de încredere, cum ar fi WinThruster (dezvoltat de Microsoft Gold Certified Partner) pentru a scana și a repara orice problemă de registru legată de opengl32.dll. Folosind un program de curățare a registrului, puteți automatiza procesul de găsire a intrărilor de registry deteriorate, link-uri către fișiere lipsă (de exemplu, provocând eroarea opengl32.dll) și link-uri rupte din registru. Înainte de fiecare scanare, a copie de rezervă, care vă permite să anulați orice modificări cu un singur clic și vă protejează de posibile daune calculator. Cea mai bună parte este că eliminarea erorilor de registry poate îmbunătăți dramatic viteza și performanța sistemului.

Avertizare: Dacă nu ești utilizator experimentat PC, NU recomandăm editarea manuală a registrului Windows. Utilizare incorectă Editorul de registry poate provoca probleme serioaseși cerere Reinstalare Windows. Nu garantăm că problemele rezultate din utilizarea incorectă a Editorului de registru pot fi corectate. Utilizați Editorul de registru pe propriul risc.

Înainte de restaurarea manuală Registrul Windows, trebuie să creați o copie de rezervă exportând partea din registru asociată cu opengl32.dll (de exemplu, FineReader OCR):

1. Faceți clic pe butonul ÎNCEPE.
2. Introduce " comanda„V bara de căutare... NU DA CLICK ÎNCĂ INTRODUCE!
3. În timp ce țineți apăsate tastele CTRL-Shift pe tastatură, apăsați INTRODUCE.
4. Va fi afișată o casetă de dialog pentru acces.
5. Clic da.
6. Caseta neagră se deschide cu un cursor care clipește.
7. Introduce " regedit" și apăsați INTRODUCE.
8. În Editorul de registry, selectați cheia legată de opengl32.dll (de ex. FineReader OCR) pentru care doriți să faceți o copie de rezervă.
9. În meniu Fişier Selectați Export.
10. Pe listă Salveaza in selectați folderul în care doriți să salvați copia de rezervă Tasta FineReader OCR.
11. În câmp Nume de fișier Introduceți un nume pentru fișierul de rezervă, de exemplu „FineReader OCR backup”.
12. Asigurați-vă că câmpul Interval de export valoarea selectată Ramura selectată.
13. Clic Salvați.
14. Fișierul va fi salvat cu extensia .reg.
15. Aveți acum o copie de rezervă a intrării dvs. de registru legate de opengl32.dll.

Următorii pași când editare manuală erorile de registry nu vor fi descrise în acest articol, deoarece sunt susceptibile de a vă deteriora sistemul. Daca vrei sa primesti mai multe informatii despre editarea manuală a registrului, consultați linkurile de mai jos.

1. În șoferi pentru placi video NVIDIA furnizate ca parte a sălii de operație sisteme Windows, suportul OpenGL lipsește de obicei. Aplicațiile vor utiliza redarea software Windows OpenGL (wrapper în Direct3D în Windows Vista). Puteți verifica prezența unui driver OpenGL în sistem utilizând utilitățile OpenGL Extensions Viewer și GPU Caps Viewer. Dacă arată că furnizorul OpenGL este Microsoft, atunci sistemul nu are un driver OpenGL. descarca si instaleaza ultima versiune Drivere pentru placa video de pe site-ul web NVIDIA.
2. ÎN versiune noua suport pentru o nouă versiune a API-ului OpenGL ar putea fi adăugat la driver, necunoscut aplicatiei. De exemplu, driverul spune aplicațiilor că acceptă OpenGL versiunea 2.0, iar aplicația/jocul verifică dacă este compatibil cu OpenGL versiunea 1.X. Pentru a rezolva problema, puteți utiliza RivaTuner în setările OpenGL din fila „Compatibilitate” pentru a forța înlocuirea șirului versiunii OpenGL raportată de driver către cea acceptată de aplicație, de exemplu, 1.5. Această opțiune nu afectează execuția OpenGL de către placa video, dar din același motiv aplicațiile care necesită OpenGL versiunea 2.0 pot înceta să funcționeze. O modalitate mai flexibilă este de a crea pentru aplicare problematică profil de driver folosind utilitarul nHancer, specificând versiunea cerutăîn opțiunea „Versiune OpenGL raportată” din fila „Compatibilitate”.
3. Problema poate apărea dacă mai multe drivere OpenGL sunt instalate pe sistem dintr-un motiv oarecare. In registrul de la adresa HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\OpenGLDrivers (HKLM\Software\Microsoft\Windows\CurrentVersion\OpenGLdrivers pentru Windows 9x-ME) verificați dacă există o singură subcheie RIVATNT și cheia Dll din această secțiune are valoarea nvoglnt (există o singură cheie cu valoarea nvopengl.dll pentru Windows 9x-ME). Dacă există alte subsecțiuni, de exemplu ati2dvag (OpenGL driver ATI), ar trebui eliminate exportându-le mai întâi într-un fișier .reg.
4. Implementarea OpenGL 2.0 pentru GPU-uri GeForce FX și o versiune superioară Driver NVIDIA necesită sprijin procesor central Extensii SSE. Dacă aceste extensii nu sunt disponibile, driverul OpenGL ICD nu va fi inițializat. aplicații OpenGL va fi închis sau va fi utilizată redarea software. Puteți verifica inițializarea driverului folosind utilitarele OpenGL Extensions Viewer și GPU Caps Viewer, puteți verifica extensiile acceptate de procesor folosind utilitarele CPU-Z sau Sandra. Dacă procesorul nu acceptă SSE, puteți fie să utilizați mai mult versiuni timpurii drivere (până la 75.XX), sau cu folosind RivaTunerîn setările OpenGL din fila „Compatibilitate”, activați în schimb modul „Modul de emulare NV25” stand implicit„Accelerație maximă”. Ca ultimă soluție, puteți utiliza OpenGL -> Direct3D wrapper GLDirect sau TitaniumGL. Uneori procesorul acceptă SSE, dar suportul nu funcționează din cauza BIOS învechit placa de baza. In mod deosebit această problemă tipic pentru sistemele cu procesoare AMD Athlon XP și Duron. Actualizați BIOS placii de baza placa poate restabili suportul SSE.
5. Dacă sistemul are mai multe plăci video bazate pe grafică diferită procesoare NVIDIA, atunci driverul OpenGL va accepta doar versiunea OpenGL acceptată de toate plăcile video.

Te întrebi: cine sunt ei? Sunt o companie moartă pe care o consider a fi adevăratul criminal OpenGL. Desigur, ineptitudinea generală a Comitetului a lăsat OpenGL vulnerabil atunci când ar fi trebuit să distrugă D3D în bucăți. Dar, după părerea mea, 3D Labs este poate singurul motiv pentru poziția actuală a OpenGL pe piață. Ce au făcut pentru asta?

Au dezvoltat un limbaj shader pentru OpenGL.

3D Labs era o companie pe moarte. GPU-urile lor scumpe au fost scoase de pe piața stațiilor de lucru prin creșterea presiunii din partea Nvidia. Și spre deosebire de nVidia, 3D Labs nu aveau nicio prezență pe piața de consum; o victorie pentru nVidia ar însemna moartea pentru 3D Labs.

Ceea ce s-a întâmplat până la urmă.

În efortul de a rămâne pe linia de plutire într-o lume care nu avea nevoie de produsele lor, 3D Labs a apărut la Conferința pentru dezvoltatori de jocuri cu o prezentare a ceea ce au numit „OpenGL 2.0”. A fost API-ul OpenGL rescris de la zero. Și acest lucru avea sens, pentru că la acea vreme API-ul OpenGL era plin de gunoaie (care, totuși, rămâne acolo până astăzi). Uită-te doar la cât de ezoteric este încărcarea și legarea texturilor.

O parte din propunerea lor a fost un limbaj shader. Da asta e. Cu toate acestea, spre deosebire de extensiile existente pe mai multe platforme, limbajul lor de umbrire a fost „nivel înalt” (C este nivel inalt pentru limbajul shader).

În același timp, Microsoft lucra la propriul său limbaj shader. Pe care ei, folosind toată imaginația lor colectivă, l-au numit... High Level Shader Language (HLSL). Dar abordarea lor față de limbă a fost fundamental diferită.

Cea mai mare problemă cu limbajul 3D Labs a fost că era încorporabil. Microsoft și-a definit limbajul complet independent. Ei au lansat un compilator care a generat cod de asamblare pentru shadere SM 2.0 (sau mai mare), care, la rândul lor, ar putea fi alimentat la D3D. La momentul D3D v9, HLSL nu a atins niciodată D3D direct. A fost o abstractizare bună, dar inutilă. Dezvoltatorul a avut întotdeauna ocazia să ia eșapamentul compilatorului și să îl modifice pentru performanță maximă.

În limbajul 3D Labs Nimic nu a fost cazul. Îi oferi driverului un limbaj asemănător C și creează un shader. Asta e tot. Nici un shader de asamblare, nimic care să poată fi alimentat cu altceva. Numai obiectul OpenGL care reprezintă shaderul.

Pentru utilizatorii OpenGL, acest lucru însemna că erau supuși capriciilor dezvoltatorilor OpenGL care tocmai învățau cum să compilați limbaje asemănătoare asamblarii. Bug-urile erau rampante în compilatoarele nou-născutului limbaj de shader OpenGL (GLSL). Ce este mai rău, dacă ai reușit să faci shader-ul să compileze corect diverse platforme(ceea ce în sine a fost o mare realizare), el era încă supus optimizatori acele vremuri care nu erau atât de optime pe cât ar fi putut fi.

A fost mare, dar nu singurul dezavantaj GLSL. Departe nu singurul.

În D3D, ca și în vechile limbaje de asamblare OpenGL, puteți amesteca și potrivi nuanțe de noduri și fragmente în toate modurile posibile. Era posibil să se folosească orice vertex shader cu orice fragment shader compatibil, atâta timp cât acestea comunicau prin aceeași interfață. Mai mult, a fost permisă chiar și o anumită incompatibilitate: de exemplu, vertex shader ar putea scoate o valoare care nu a fost folosită de fragment shader.

Nu a existat așa ceva în GLSL. Vertexul și umbrirea fragmentelor au fost fuzionate împreună pentru a forma ceva 3D Labs numit „obiect software”. Prin urmare, pentru partajarea mai multe shadere de noduri și fragmente în diverse combinații, a fost necesară crearea mai multor obiecte software. Aceasta a cauzat a doua cea mai mare problemă.

Laboratoarele 3D au crezut că sunt cele mai deștepte. Au folosit C/C++ ca bază pentru modelul de compilare GLSL. Acesta este momentul în care luați un fișier c și îl compilați într-un fișier obiect, apoi luați mai multe fișiere obiect și le legați într-un program. Acesta este modul în care se compilează GLSL: mai întâi compilați un vertex sau fragment shader într-un obiect shader, apoi puneți acele obiecte într-un obiect program și le legați împreună pentru a forma în sfârșit un program.

În teorie, acest lucru a permis lucruri interesante, cum ar fi shaderele „bibliotecă”, care conțin cod care este numit de shaderul principal. În practică, acest lucru a dus la necompilarea nuanțelor de două ori: o dată la etapa de compilare și a doua oară la etapa de legătură. În special, compilatorul de la nVidia a fost renumit pentru asta. Nu a generat niciun cod obiect intermediar; a compilat la început, a aruncat rezultatul și a compilat din nou în stadiul de link.

Astfel, pentru a atașa un vertex shader la două fragment shader diferite, a trebuit să compilați mult mai mult decât în ​​D3D. Mai ales având în vedere că toată compilarea este făcută deconectat, și nu înainte de execuția efectivă a programului.

GLSL a avut și alte probleme. Ar putea fi greșit să punem toată vina pe 3D Labs, deoarece ARB a aprobat și a inclus limbajul shader în OpenGL (dar nimic altceva din propunerile 3DLabs). Cu toate acestea, ideea originală a fost încă cu 3D Labs.

Și acum cel mai trist lucru: 3D Labs au fost au dreptate(Mai ales). GLSL nu este un limbaj vectorial ca HLSL la acea vreme. Acest lucru se datorează faptului că hardware-ul 3D Labs era scalar (cum ar fi hardware-ul modern nVidia) și au avut dreptate în a lua direcția pe care au urmat-o mai târziu mulți producători de hardware.

Au avut dreptate în alegerea modelului de compilare pentru limbajul „la nivel înalt”. Până și D3D a ajuns în cele din urmă la asta.

Problema este că 3D Labs a avut dreptate și greșit timp. Și încercând să pătrundă prematur în viitor, încercând să fie pregătiți pentru viitor, ei lasă deoparte prezentul. Aceasta arată ca funcționalitatea T&L din OpenGL care a fost întotdeauna acolo. Cu excepția faptului că conducta OpenGL T&L a fost utilși înainte de apariția hardware-ului T&L, iar GLSL era o răspundere înainte ca restul lumii să ajungă din urmă.

GLSL este limbaj bun Acum. Dar ce s-a întâmplat în acel moment? Era groaznic. Și OpenGL a suferit din cauza asta.

În drum spre apoteoză

Susțin opinia conform căreia 3D Labs i-a dat lovitura de moarte lui OpenGL, dar ARB însuși a bătut cu ciocanul final în sicriu.

Poate ați auzit această poveste. La momentul OpenGL 2.1, OpenGL avea mari probleme. El târa de-a lungul imens sarcina de compatibilitate. API-ul nu mai era ușor de utilizat. Un lucru se poate face cu cinci căi diferiteși nu este clar care dintre ele este mai rapidă. A fost posibil să „învățați” OpenGL prin ghiduri simple, dar nu ați studiat OpenGL care dă real putere grafică si performanta.

ARB a decis să facă o altă încercare de a reinventa OpenGL. A fost ca „OpenGL 2.0” de la 3D Labs, dar mai bine pentru că ARB a fost în spatele efortului. L-au numit „Vârful Lungilor”.

Ce este atât de rău în a petrece puțin timp îmbunătățind API-ul? Vestea proastă este că Microsoft se află într-o poziție destul de precară. Era timpul pentru trecerea la Vista.

În Vista, Microsoft a decis să facă modificări mult așteptate la drivere grafice. Au forțat șoferii să apeleze la sistemul de operare pentru virtualizare memorie graficăși multe altele.

Se poate discuta mult timp despre meritele acestei abordări și dacă a fost chiar posibilă, dar adevărul rămâne: Microsoft a făcut D3D 10 doar pentru Vista și mai sus. Chiar și pe de susținere Era imposibil ca hardware-ul D3D să ruleze o aplicație D3D fără Vista.

Poate vă amintiți că Vista... să spunem că nu a funcționat foarte bine. Deci am avut un sistem de operare pe îndelete, nou API, care a funcționat doar pe acest sistem de operare și noua generație de hardware, care Necesarîn acest API și OS pentru a face mai mult decât să depășească generația anterioară.

Cu toate acestea, dezvoltatorii ar putea Utilizați funcționalitatea nivelului D3D 10 prin OpenGL. Adică ar putea dacă ARB nu ar fi ocupat să lucreze la Long Peaks.

ARB a petrecut un an bun și jumătate până la doi ani lucrând la îmbunătățirea API-ului. În momentul în care a apărut OpenGL 3.0, tranziția la Vista se terminase, Windows 7 era pe drum, iar dezvoltatorilor de jocuri nu le mai păsa de funcționalitatea D3D 10. La urma urmei, hardware-ul D3D 10 a funcționat bine cu aplicațiile D3D 9 ritmul de porturi PC a crescut, consola (sau odată cu tranziția dezvoltatorilor de PC-uri pe piața consolelor), dezvoltatorii aveau nevoie din ce în ce mai puțin de funcționalitatea D3D 10.

Dacă dezvoltatorii ar avea acces la această funcționalitate chiar și pe Windows XP, dezvoltarea OpenGL ar putea fi revigorată. Dar ARB a ratat această ocazie. Vrei să știi care este cel mai rău lucru?

ARB a eșuat inventați un API de la zero, în ciuda faptului că ați pierdut doi ani prețioși încercând să o faceți. Așa că au returnat status quo-ul, adăugând doar un mecanism de depreciere a funcționalității.

Drept urmare, ARB nu numai că a ratat cheie oportunități, dar nici nu au făcut munca care i-a condus la această omisiune. A fost un eșec epic pe toate fronturile.

Aceasta este povestea confruntării dintre OpenGL și Direct3D. O poveste despre oportunități ratate, mare prostie, nesăbuință voită și absurdități banale.