GL_INVALID_ENUM v SwapBuffers ?

[Játro.m]

Nazdar,

mám tu jednu prekérní situaci, projekt mi sundává ovladače na ATI a už z toho začínám být nešťastnej, takže situace je následující.

Několikrát jsem debugoval v gDEBUGeru a dostal sem že chyba je GL_INVALID_ENUM a podle něj a call stacku je v SwapBuffers(), což mi připadne jako blbost, když je to čistě wokenní fce pokud se nepletu.

Tuto chybu dostanu jenom jednou a to v 7mým frámu, když krokuju. Kód jsem si procházel 100x a prostě nic jsem nenašel, když pozvypínám veškerej rendering ve vláknech, tak ta chyba je tam furt.

Jakmile zakomentuju SwapBuffers, tak to sice nespadne ale problém je že nejde render nečekaně

HDC co mi leze do SwapBuffers se nemění, podle toho co jsem se díval.

Dokázal by mi někdo říct co jsem po*ral?
Dík, šedivím z toho :/

[if.then]

Bude to znít obligátně, ale...

Kód?

Jinak GL_INVALID_ENUM je docela nestandardní error, nemělo být tak těžké kouknout se do man pages a zjistit, které funkce ho mohou evokovat.
_________________
For guns and glory, go to www.ceske-hry.cz.
For work and worry, execute VC++.

[Játro.m]

ajaj vole, ty seš chytrej hoď si do googlu invalid enum a vyber mi funkci co to dělá ono v renderu se jich volá docela víc který to můžou bejt.

Kód, no, budeš se probírat 150 fajlama kterejm nerozumíš?
kdybych tušil kde to je, tak nepíšu semka hele pár takovejhle chybiček jsem už zažil ale debugger mě rovnou hodil na místo kde to krešlo, tady ne-e :/

a konkrétně mě zajímá, jestli už to někomu je*alo na tom swapu

[johnnash]

Po tom co sem zazil s ATI driverama tak tam klidne muze byt i bug...

[nou]

skusit iny system s inou kartou. ono to fakt moze byt bug v ovladacoch. ono nech robis cokolvek tak by sa ti neamo dat sundat ovladac.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[pcmaster]

Ja som nakoniec s CL/GL dopadol tak, ze som mal za KAZDOU funkciou getError :] Takze sa uisti, ze sa ti neposere nejake volanie uz predtym.
Ci je to ATI, ci NVIDIA, skus inu verziu driveru, spravaju sa dost casto odlisne

A ked sme pri tom... urcite by sa neoplatilo komplet vsetko renderovat do textur(y) a potom rucne swapnut do widgetu/obrazovky/suboru/siete/kamkolvek? Takyto rucny blit sotva bude uzkym hrdlom... Chapete, co myslim? Predpokladam, ze sa to nerobi cisto z dovodu, ze to predsa len bude kusocek pomalsie nez priame kreslenie...

(Asi som zdeformovany "offline" rasterizatorom z prace, par desiatok ci stoviek milisekund hore dole nikomu ani nepozdvihne obocie )
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Játro.m]

jo, zapoměl jsem napsat že se to objevuje v gDEBUGeru aji na NV, takže je to nějaká pitchovina v kódu, ale NV má aspoň ovladače který hnedka nekrešnou. Problém je ten, že zakomentuju celej render - nechám jenom while s swapbuffers, všechny vlákna a chyba nezmizí. Jakmile se zbavím swapbuffers tak to jde, ale myslím si že to bude jenom odkaz na nějakou předchozí chybu, co to způsobuje .. je to rozbitý

[nou]

skus zakomentovat cely render a nechaj iba tie swap buffers.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[]semo[]

Zkus se ještě podívat na vytváření okna, na takové ty wgl funkce. A pokud je používáš, zkus místo SwapBuffers dát (aspoň provizorně) wglSwapLayerBuffers (nebo jak se to jmenuje).

A zkusil bych to na chvíli bez gDEBuggeru. A to takhle (před swap zavolat getError naprázdno):

[Játro.m]

nou: celej render jsem zakomentoval, dokud tam není SwapBuffers tak to jede v pohodě jinak invalid enum

semo: zkoušel jsem obě varianty, změna žádná, chyba se nevypsala žádná, na ATI lag při swapu bufferu.
tady je zdroják initu wokna, protože chyba musí bejt tady asi :/
http://nopaste.ceske-hry.cz/223347

kontroloval jsem si to, ale třeba jsem si něčeho nevšiml :/

[]semo[]

Tyjo, proč si nezmínil, že používáš multithreading? To pak může dělat všelijaký pohádkový chyby.

Zkus klasiku bez threadů:

[Játro.m]

jo, o MT jsem se krapet zapoměl zmínit, já blb
v klasické smyččce to nepadne.

ten erasebg se vykreslí jenom když to zamrzne

takže co rozhodí multithreadovanej render, že nejde když fungoval? Toť otázka teda WTF

[]semo[]

To ti povím, co rozhodí :-) Různý windows message dělají něco s oknem...do toho přijde SwapBuffers s druhýho threadu a dělá opět něco s oknem. Takže tu máme dva thready, který můžou dělat v jeden a ten samej čas nějakou operaci s jednou věcí. Nevíme sice co přesně je špatně, ale pokud tam nebudeš mít nějaký synchronizační prvky pro thready, tak se budeš dočkávat podobných radostí.

Nevím, proč chceš druhý thread na kreslení, jediný použitelný případ co mě napadá je, když chceš kreslit do okna i během tažení (i to se dá obejít, ale neni to dokonalý). Thready bych doporučil použít na něco lepšího (nějaké delší výpočty, animace, ...).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[pcmaster]

Presne tak, kreslit takto ad-hoc z viacerych vlaken je fakt vrazda a budes mat problemy to oddebugovat. Urcite by som nechal kreslit jedine vlakno a ostatne by boli na nieco ine. Ale v kazdom pripade nech len jedno jedine vlakno (a to bude hlavne vlakno, ktore okno vytvori) manipuluje s oknom a kontextami, atd. To sa ti velmi osvedci, ak budes musiet pouzit frameworky ako Qt, kde je dost vynutena prislusnost roznych objektov k vlaknam, ktore ich vytvoria.
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Marek]

OpenGL nejde používat z více vláken zároveň. Pro thread-safety je fakt lepší, aby správa okna i OpenGL běželo pod jedním vláknem (ono to stejně ani jinak funkční udělat nejde).
_________________
AMD Open Source Graphics Driver Developer