Šta je novo?
Od:
Filteri

Ati баг...

3MaJ

3MaJ

Čuven
Učlanjen(a)
06.04.2001
Poruke
283
Poena
619
Мислим да сам пронашао баг у ATI драјверу (или картици) који користим. Тиче се погрешног заокруживања при рендеровању 4-битних колор компоненти у текстуру. Замолио бих да неко, уколико има времена и ATI картицу, покрене овај програмчић код себе и пошаље ми генерисани текстуални фајл.

Програмчић не испитује компатибилност картице са проблематичном OpenGL екстензијом, тако да је могуће да ће пући. Код мене (x1800) ради, а теоријски би требало да ради и на свим картицама почев од 9K серије на овамо.

Моја адреса је
chief 'at' verat.net
 

Prilozi

  • TestATI.rar
    165 KB · Pregleda: 91
Ех, да...
Замолио бих и да напишете модел графичке картице и верзију драјвера у mail-у.
 
Hm. Opste poznato je da Ati kartice imaju problema sa OpenGL drajverima, i da u profi upotrebi veoma brljave. Na netu imas diskusija koliko hoces.
Kada nadjem malo vremena probacu i ovo tvoje programce.
 
Kaze: FBO wrong!
HW: GeForce 5600Go, 128MB,
driver: 91.28
OS: XP SP2

Ajde okaci src gde pravis taj FBO, jer ja nemam problema sa FBO u mojim programima.
 
Pukne aplikacija, a izlazni fajl je 0 bytes

HW: ATI FireGL V3100
driver: 8.043.1.1 (stigli uz masinu)
OS: XP SP2
 
ATI 9550 (by Sapphire mada nije bitno)
default clock 250/200, cat 6.4 + ati tray tools, XP SP3 (=SP2 od decembra)
Okacicu ovde da i drugi vide o cemu se radi.
 

Prilozi

  • out.txt
    9.4 KB · Pregleda: 93
Poslednja izmena:
yooyo je napisao(la):
Kaze: FBO wrong!
HW: GeForce 5600Go, 128MB,
driver: 91.28
OS: XP SP2

Ajde okaci src gde pravis taj FBO, jer ja nemam problema sa FBO u mojim programima.
Kliknite za proširenje...

Да, зато што је на FBO прикачена текстура формата GL_RGBA4.То на NVidia картицама не ради, једини типови 16-битних FBO са којима оне раде су GL_LUMINANCE16 i GL_LUMINANCE8_ALPHA8.

Да вас обрадујем, исти "баг" сам приметио код свих који су ми послали извештај. Да ствар буде занимљивија, начин на који се грешке испољавају различит је од картице до картице.

Баг сигурно нико никад неће приметити (осим ако се не бави GPGPU послом), тако да мислим да нема сврхе сада дизати панику око тога. То вероватно може нанети више штете него користи. Сачекаћу одговор ATI developer relations тима, па уколико га не буде, објавићу детаље.

Узгред, ако је неко добар са ATI-јем, било би лепо да ме повеже с њима. На њиховом сајту, када одем на "Contact us", добијем само формулар у коме треба да попуним податке о својој "компанији" и "производу", након чега они треба да одлуче да ли ћу моћи да их контактирам или не. Крајње арогантно... Послао сам опис проблема на [email protected], надам се да није отишао у junk.

Хвала свима на помоћи. :)
 
Transdcend Ati 9200 64MB/128bit, Cat 6.4 WinXP pro sve default - posle 2 sek. izbaci onaj prozor sa "Send report..".
 
Poslednja izmena:
Bilo bi lepo da nam kazes o cemu se radi. Mozda je neko dobar sa ATI-jem pa ti i pomogne ... Mislim ok...ulozili smo malo vremena i strpljenja oko ovoga, korektno bi bilo da nam kazes sta je.. pogresno kvantifikovanje vrednosti tj zaokruzivanje???
 
Poslednja izmena:
Ок...
Као што вероватно знате, постоји могућност да се геометрија не рендерује само на екран, већ и у текстуру. У те сврхе, у OpenGL-у, постоји такозвани FBO (Frame buffer object).

Када се на њега прикачи 16-битна текстура (на пример GL_RGBA4, која има 4 4-битне компоненте), догађа се да због грешке у заокруживању боја у текстури након рендера буде различита од жељене.

Е, сад мало детаљније о заокруживању.
На пример, боја (0.0, 0.0, 0.21875) ће се рендеровати као (0.0, 0.0, 0.26667). Дакле, извршиће се некакво заокруживање боје коју желим да нацртам на одговарајући ниво условљен бројем бита којим се колор компонента представља. И то је нормално.
Али, боја (0.0, 0.0, 0.25), која је светлија него (0.0, 0.0, 0.21875), погрешно ће бити заокружена на (0.0, 0.0, 0.2), што је тамније него (0.0, 0.0, 0.26667)!
Још горе, боја (0.0, 0.0, 0.0625), коју OpenGL при цртању на екран растеризује као тамноплаву, при рендеровању у текстуру претвориће се у црну!

Ево и једног исечка из out.txt фајла:

42: 0.164063 quantized to 0.2
43: 0.167969 quantized to 0.2
44: 0.171875 quantized to 0.133333
45: 0.175781 quantized to 0.2
46: 0.179688 quantized to 0.2

Дакле, колор компонента 0.171875 необјашњиво се заокружује као 0.13333, иако се све боје у њеној околини заокружују као 0.2

Визуелно, ово нема практично никаквог утицаја (сумњам да неко данас користи 16-битне текстуре, а све и да их користи, један ниво горе-доле се тешко примећује). Ипак, уколико се 16-битни render to texture користи у GPGPU прорачуну, баг може бити јако непријатан.

Edit: Сад приметих да ми је ово 255. пост. Каква иронија :)
 
Poslednja izmena:
Ako koristis shadere, napravi jednu 1D texturu 16x1 i u nju upisi vrednisti koje zelis. Zatim tu texturu koristi kao lookup pre upisa u FBO. Ukljuci nearest filtering na ovoj 1D texturi da bi izbegao filtriranje. Na ovaj nacin ces iz shadera kontrolisati izlaz.

Inace... pokusaj da se obratis Humusu (www.humus.ca) jer on radi za ATI. Na tvoje pismo verovatno niko nece odgovoriti iz ATI-a.
 
Da li si apsolutno siguran da ne postoji neka greška u aplikaciji. Prosto neverovatno da sva jezgra svih generacija imaju grešku iste vrste?

Greška se potpuno sistematično javlja u svim intervalima.
 
Možda zato što su odavno prešli na interno 32-bitno baratanje bojama i zabole ih za 16-bitne?
 
Jos jedno pitanje.... da nemas problema sa ditheringom? Probaj da na pocetku renderinga ubacis
glDisable(GL_DITHER);
i opciono glHint(GL_POLYGON_SMOOTH_HINT, GL_FASTEST);
 
Poslednja izmena:
MSI X800
cat 6.4
xp pro sp1
nista clock sve default
 

Prilozi

  • out.txt
    9.4 KB · Pregleda: 51
nidza je napisao(la):
Da li si apsolutno siguran da ne postoji neka greška u aplikaciji. Prosto neverovatno da sva jezgra svih generacija imaju grešku iste vrste?

Greška se potpuno sistematično javlja u svim intervalima.
Kliknite za proširenje...

Kod: 
#include <stdio.h>
#include <stdlib.h>
#include <GL/glew.h>
#include <GL/glut.h>

#include <fstream>
using namespace std;

static texSize = 8;
static GLenum textarget = GL_TEXTURE_2D;
static GLenum texinternalformat = GL_RGBA4;

int main(int argc, char **argv) {
    ofstream fout;
	fout.open("out.txt");

	// declare texture size, the actual data will be a vector 
    // of size texSize*texSize*4
    // create test data and fill arbitrarily
    float* data = (float*)malloc(4*texSize*texSize*sizeof(float));
    float* result = (float*)malloc(4*texSize*texSize*sizeof(float));
	glDisable(GL_DITHER);
	glHint(GL_POLYGON_SMOOTH_HINT, GL_FASTEST);


	// Make a 256-element texture. 
	//Each element is +1.0/256 greater than the previous one. 
	for (int i=0; i<4*texSize*texSize; i++)
		data[i] = ((float)i)/256.0;

	// set up glut to get valid GL context and 
    // get extension entry points
    glutInit (&argc, argv);
    glutCreateWindow("TEST1");
    glewInit();
    // viewport transform for 1:1 pixel=texel=data mapping
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    gluOrtho2D(0.0,texSize,0.0,texSize);
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    glViewport(0,0,texSize,texSize);
    // create FBO and bind it (that is, use offscreen render target)
    GLuint fb;
    glGenFramebuffersEXT(1,&fb); 
    glBindFramebufferEXT(GL_FRAMEBUFFER_EXT,fb);
    // create texture
    GLuint tex;
    glGenTextures (1, &tex);
    glBindTexture(textarget,tex);
    // set texture parameters
    glTexParameteri(textarget, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
    glTexParameteri(textarget, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
    glTexParameteri(textarget, GL_TEXTURE_WRAP_S, GL_CLAMP);
    glTexParameteri(textarget, GL_TEXTURE_WRAP_T, GL_CLAMP);
    // define texture with floating point format
    glTexImage2D(textarget,0,texinternalformat,texSize,texSize,0,GL_RGBA,GL_FLOAT,0);
    // attach texture
    glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, textarget,tex,0);
    glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);

	int fboOK = 0;
	GLenum status = glCheckFramebufferStatusEXT( GL_FRAMEBUFFER_EXT );
	fboOK = (status==GL_FRAMEBUFFER_COMPLETE_EXT);
	if (fboOK)
	{
		glRasterPos2i(0,0);
		glDrawPixels(texSize,texSize,GL_RGBA,GL_FLOAT,data);
		glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
		glReadPixels(0, 0, texSize, texSize,GL_RGBA,GL_FLOAT,result);
		// print out results
		for (int i=0; i<texSize*texSize*4; i++)
			fout << i << ":\t\t" << data[i] << "\t quantized to " << result[i] << "\n";
	}
	else
		fout << "FBO wrong!";
	// transfer data to texture

	fout.close();
	free(data);
    free(result);
    glDeleteFramebuffersEXT (1,&fb);
    glDeleteTextures (1,&tex);
    return 0;
}

А баш да је систематично, и није. Пре ми делује као тотално хаотично. И што је највећа фора, грешке у квантизацији на x800 и x1800 се разликују, али постоје и на једној и на другој!

Пошто текстура уопште не силази са графичке картице, веома сам склон да верујем да је грешка у хардверу, али не желим да спекулишем...
 
yooyo je napisao(la):
Ako koristis shadere, napravi jednu 1D texturu 16x1 i u nju upisi vrednisti koje zelis. Zatim tu texturu koristi kao lookup pre upisa u FBO. Ukljuci nearest filtering na ovoj 1D texturi da bi izbegao filtriranje. Na ovaj nacin ces iz shadera kontrolisati izlaz.
Kliknite za proširenje...

То је немогуће. Коју год боју да рендерујем из shader-а, она се пре излаза прво своди на целобројни умножак од 1.0/16. Онда се због овог чудног рендеровања у текстуру "презаокружи" сходно "новој" квантизационој табели, што често може да да другу боју.

Помислио сам да је можда неки драјверски баг, те да линеарно филтрирање остаје укључено иако сам изабрао NEAREST, али погледом на саме резултате, немам никакав утисак да је ту било шта линеарно филтрирано.
Још занимљивије је да су резултати квантизовани на 15 нивоа, уместо на 16!
 
Poslednja izmena:
Ипак се ради о dithering-у. Рекоше ми из ATI-ја да је dithering подразумевано укључен када се ради са 16-битним текстурама, а искључен када се ради о 24 или 32-битним. Није баг него feature :)
 
Poslednja izmena:
I sta ces sad? Jel moze da se iskljuci taj feature?
 
Vidiš da se sam isključuje kad nije u 16-bitnoj paleti.

BTW, što je uopšte testirano u 16 bita?
 
Zato sto coveku treba za GPGPU, a to nije neka nova igrica, vec upotreba graficke kartice za raznorazne proracune. Problem je sto driver ne radi kako treba jer ignorise komandu za dither.
 
Heh, zaboravio sam da ponesem od kuce fajl. Ali kako sam ga sinoc proucavao:
- greska se sistematski ponavlja, ne od starta, negde kod vrednosti iznad 0.2xxx kolko se secam, i ne kod svih sekvenci iteracija.
Ati X800Pro sa otkljucanim pajpovima(svih 16, trenutno na default klokovima).
Ne verujem da je to bas greska hardvera. Mada nije ni iskljuceno, jer ATi cipovi su dizajnirani strogo po DirectX specifikacijama, dok su OpenGL ignorisane. Uglavnom se profesionalci zestoko zale na njihove drajvere, mada...
 
BokiPK je napisao(la):
Ne verujem da je to bas greska hardvera. Mada nije ni iskljuceno, jer ATi cipovi su dizajnirani strogo po DirectX specifikacijama, dok su OpenGL ignorisane. Uglavnom se profesionalci zestoko zale na njihove drajvere, mada...
Kliknite za proširenje...

Ма није хардвер, него драјвер по default-у укључује dithering за 16 битне текстуре, иако то није документовано. Онда светлије боје местимично заокружи као тамније, како би се на градијенту видео постепенији прелаз.
 
Da, najverovatnije.
Evo:
 

Prilozi

  • out.txt
    9.4 KB · Pregleda: 29
PowerColor X800GT sa flashom od X800GTO
Cat. 6.5
 

Prilozi

  • out.txt
    9.4 KB · Pregleda: 47
3MaJ je napisao(la):
Ок...
Као што вероватно знате, постоји могућност да се геометрија не рендерује само на екран, већ и у текстуру. У те сврхе, у OpenGL-у, постоји такозвани FBO (Frame buffer object).

Када се на њега прикачи 16-битна текстура (на пример GL_RGBA4, која има 4 4-битне компоненте), догађа се да због грешке у заокруживању боја у текстури након рендера буде различита од жељене.

Е, сад мало детаљније о заокруживању.
На пример, боја (0.0, 0.0, 0.21875) ће се рендеровати као (0.0, 0.0, 0.26667). Дакле, извршиће се некакво заокруживање боје коју желим да нацртам на одговарајући ниво условљен бројем бита којим се колор компонента представља. И то је нормално.
Али, боја (0.0, 0.0, 0.25), која је светлија него (0.0, 0.0, 0.21875), погрешно ће бити заокружена на (0.0, 0.0, 0.2), што је тамније него (0.0, 0.0, 0.26667)!
Још горе, боја (0.0, 0.0, 0.0625), коју OpenGL при цртању на екран растеризује као тамноплаву, при рендеровању у текстуру претвориће се у црну!

Ево и једног исечка из out.txt фајла:

42: 0.164063 quantized to 0.2
43: 0.167969 quantized to 0.2
44: 0.171875 quantized to 0.133333
45: 0.175781 quantized to 0.2
46: 0.179688 quantized to 0.2

Дакле, колор компонента 0.171875 необјашњиво се заокружује као 0.13333, иако се све боје у њеној околини заокружују као 0.2

Визуелно, ово нема практично никаквог утицаја (сумњам да неко данас користи 16-битне текстуре, а све и да их користи, један ниво горе-доле се тешко примећује). Ипак, уколико се 16-битни render to texture користи у GPGPU прорачуну, баг може бити јако непријатан.

Edit: Сад приметих да ми је ово 255. пост. Каква иронија :)
Kliknite za proširenje...
Rydermark benchmark alleges Nvidia fudge

16 bit textures only, not 32 please, breaking DX9 specs

By Fuad Abazovic: Tuesday 04 July 2006, 10:22

GAME developers on an upcoming boat racing benchmark, entitled Rydermark alleged that one of the two graphic vendors is fudging the truth with its per pixel precision. DirectX 9 requires you to use at least 24 bit or full 32-bit Shader precision.

Nvidia doesn’t let developers use more than 16 bit and of course it is much faster than 32 bit precision. The only problem is that 16 bit precision is below the requirements of DirectX 9, so if you use less than 24 you are not DirectX 9 compliant.

If you want to do normal mapping, parallax mapping and water reflection/refraction, your Shader requires 32 bit precision.

Nvidia doesn’t leave you any choice, it's claimed. You simply cannot turn 24 or 32 bit precision on, you are always locked at 16 bit. From a developer and artistic perspective this is really unacceptable but will buy you a few frames here and there.

Developers have also informed us that they have no way to stop Nvidia doing this. The only way is to make the community aware, and that can change some minds. There is more to come and we will try to get you screenshots to really see the difference. :wave:

izvor

da li ce se vlasnici 'zelenih', nakon ovoga, vise ikada hvaliti svojim karticama? nakon sramote od pre par godina kada su u drajverima premoscavali 3dmark da bi napumpali rezultate, nvidija je pribegla jos jednom niskom i sramnom triku. secam se kada se kvalitet prikaza u nekadasnjim mikroracunarima pocetkom devedesetih merio prema ati-jevim karticama, pa su konkurentske kartice dobijale 0.7, 0.8, 0.9 ati-ja. drago mi je da je ati ostao dosledan kvalitetu prikaza za razliku od 'zelenih' koji mazu oci prljavim trikovima.

ps: ati by ATi(r) 9500@9700 (softmodovan, otkljucani svi gpu-pajpovi) 128MB 256bit, directx9c, winxp pro sp2, catalyst 6.4 (8.241.0.0)
 

Prilozi

  • out.txt
    9.4 KB · Pregleda: 25
Poslednja izmena:
to je davna istorija, a imao je i ATI svojih. Uostalom u ono vreme to je bilo cost-effective resenje, u gamingu se nije ni obracala paznja na to tako da nas je boleo k***

takodje seti se i ko je ATI-ju uopste otvorio put na trziste ubivsi 3dfx, ko je smislio HW T&L i jos mnogo toga sto je ATI dobio na tanjiru kada je usao u trku...

ATIjeva doslednost kvalitetu se vidi trenutno u softshadows prikazima, AA + shadows bugovima i tako to. Nije ni u ATI-ju sve tako crno-belo. Ne zaboravimo njihov revolucionarni "true form" koji je namazao ne oci, nego nego celo telo kupcima, takodje ne zaboravimo dx9 vista ready kartice koje sada prodaju, ne zaboravimo podvaljivanje 4x2p moda AA kao 4x AA setinga u drajverima, 16x superior AF na nivou vidijine 8x i tako ima toga moze se kesa cela nakupiti i sa jedne i sa druge strane, ali ovo nije topik za to.
 
Poslednja izmena:
nijedno atijevo maskiranje filtera nije ni izbliza tako bezocno kao sto je prodavanje 16-bitnih shadera za 32-bitne. zaista bi valjalo uporediti performanse atijevih kartica u 16-bit color okruzenju, nesto mi se cini da bi x1900 oduvao 7800-ku daleko ubedljivije.

u pravu si, ovo nije tema za takvu raspravu.
 
Poslednja izmena:
Morate se prijaviti ili registrovati da odgovorite ovde.
Vrh Dno