pouët.net

I just want to point out a thing that many opengl developer miss, including me :)

This is a small but that not many people recognized before, but the latest radeon driver arent possible to force to a special mode, so the but is therefor more visible there.

the bug in question is the one that makes every texture 16bit.

the main reason is that early in opengl you could only specify how many componets an image had ( 3rd parameter of glTexImage2D ). But thats really old news, i think it was the specification for opengl 1.0 that stated that parameter as 'componets', earlier version ( and i think its opengl1.1) changed the parameter to 'InternalFormat' and can now take a number of different format hints, look here. The value 3 responds to GL_RGB and this means that you have no interest in the quality, you just let opengl decide for you, and often that means that you get speed over quality ( with one exception), and thats not what we want in demos. GL_RGB8 and GL_RGBA8 lets the driver know that we really want 24 or 32 bit quality and the driver can act accordingly. The same goes for GL_RGB4 and GL_RGBA4 that says that 16bits is file ( i dont know when you want that, but you save memory).

now the exception, and the current bug.
In nVidia and ATI's controlpanels you can set a quallity slider, when you set low everything becomes 16bit, in the middle the undefined (4, or GL_RGBA) and GL_RGBA4 becomes 16bit and GL_RGBA8 becomes 32bit, just as 'normal'. And in HighQuality everything becomes 32bit. In the latest ATI drivers the HighQuality doesnt work, and therefor everything undefined becomes 16bit, and the same will happen on all computers where you let the slider stay on 'default' so its not only ati that fails on that.

The reason for this message? well, its become apparent that many demos ( including Schism from noice) has this 'setting' and therefor it looks worse that it has to.. and i bet its not only on ati, but except for nVidia cards ATI are the most common among the people on this board. Please take a look at your opengl engines and codes and just make sure that the 3rd parameter in texture upload functions have a quality value on them.. I have made the changes for our next demo.

Thanks, and happy coding
/Mazy of Noice

why don't you email devrel@ati.com ?

since this is first a developer bug, and only second a driverbug, i bet ati fix it in the next drivers, but you should still make sure that you ask for the correct format for your driver, and then the demo will work on cards without quality setting, and on computers with the setting 'default'

thanx for the note, though I didn't realize quality problems yet.
but gonna check my codes.
happy coding as well :)

already had this problem. the asm03 demo from kewelrs has the same problem too. it's not a driver bug, that's right. ;)

bling bling!

Kewlers' demos use the old GL_RGB(A) formats, but that's only because Curly Brace wants his code to work on wide spread of gfx cards. Forcing some certain bpp modes might lead to less compatible demos... But i guess we might consider adding the fix to the "shitty radeon"-mode :) Thanks Mazy!

if you find one driver that doesnt work with GL_RGBA8 please tell me.. it in the Opengl 1.1 spec.

And i still havent noticed any difference between the shitty radeon and normal mode ( having a radeon)

oh, and its not a 'force' its a 'hint', if the current card or gfxmode cant handle it, the driver can ignore it.. ts just that GL_RGB(A) tells the driver that you really doesnt care, and if Kewlers doesnt care att all about the quality of the output, then I guess is fine to watch it in 16bit :)

You're right, kewlers don't care about the quality of the output :)

The "shitty radeon" -mode disables the use of some effects that use the glCopyTexSubImage2d-function. At least some Radeons don't support it in hardware-level (we got a lot of complaints that GLitch ran around 1fps with Radeon 9000-gpus).

In asdntc it's the ugly horizontal glitter/whatever-effect that shows in the beginning and in the buddha-scene...

But back to the subject... I might get Curly to do an updated version of asdntc and protozoa as well, which both suffer from the 16bit-issue with non-nvidia cards.

Rainmaker: is the glCopyTexSubImage2d-function also responsible for the credits of 'Protozoa' running at an "impressive" 1.5 spf on a Radeon 9700Pro with certain driver versions?

Shifter, don't think so. Must be something with the drivers since the credits-part doesn't use anything unusual except glBlendFunc(GL_ZERO, GL_ONE_MINUS_SRC_COLOR); but so does the whole first part of the demo... Is it only the credits-sequence or the logos too? And is it slow only with _certain_ drivers? If it is, then it's a driver problem.

I also noticed that the latest ATI catalyst drivers generally have a performance problem with
"procedural" textures which are frequently uploaded
from sys to gfx mem using e.g. glDrawPixels()

this call seems to be 2-3 times slower on my
1GHz AMD+Radeon9500pro than e.g. on my P2-400+Geforce2 (!!)

on the other hand, e.g. GL lighting is really fast with ATI cards but this will probably be not used in demos anyway

you shoudnt update textures from system mem.. you have fragment programs, and render to texture :)

> "procedural" textures which are frequently uploaded
> from sys to gfx mem using e.g. glDrawPixels()

glDrawPixels to draw a dynamic texture? lol...
not surprising this is slow either anyway, because gldrawpixels is a blocking call for the driver which results in breaking the cpu/gpu paralellism. I'll explain more when i will write the articles i'd like to write about that topic.

dynamic textures have to be uploaded with glTexSubImagexd (x = 1..3). (the 1D version doesn't works correctly on current ATI drivers) .you can also notice that a generic extension which allows the application to allocate textures in agp memory is under work (ARB_pixel_buffer_object). the proprietary nVidia extension for this feature is avialable.

GL lighting is very beautifull (phong lighting by default) and very used in demos.

fragment programs shouldn't be used yet in demos (feature equivalent to d3d9 pixel shaders 2). it isn't enough spread on current pcs (requires geForceFX, radeon9500+).

I'd just like to disagree with nystep's last comment - use fragment programs if you REALLY need it to make that amazing effect you always wanted to make. But make sure to have a divx ready, and prepare to be massively flamed by people who are too impatient to wait a year or two tilll the dx9 cards are affordable :)

Personnaly, I love to see high end demos, and as long as there's a divx around, I can wait to see it.

Rainmaker: well, it started with upgrading catalyst 3.4 drivers, so unless you're ready to joke about ati's crappy driver support, no dice ;)

And I'm not sure what you consider logos, but I am referring to the introductionary titles/credits with a bumpmappy feel to it. The 3d scenery ran nicely but things grinded to a halt whenever the text popped up.

sure psonice, if you like flames, you can use them... ;)

The other problem of fragment programs is their excessive slowlyness on nVidia cards: don't excpect much more than 40 FPS on a geForceFX 5200 at 1024*768 with only 6 instructions in the program...

The trick to acheive higher frame rates on such hardware is to render the whole scene to the depth first, and then only apply fragment shaders, it makes an intelligent use of the latest's cards early Z test, by discarding useless fragments. But of course it makes your effects use 2 passes. That's a deal.

Use fragment programs in opengl if you wanna use shaders, since they are not vendor specific.. whats nystep wrote was (as usually) pure shit..

stefan u don't know shit to programming u make me laugh =))

FLAMEWAR!!1