Fast Dynamic Lighting

[mh]

[mh]

.

[Baker]

I find it interesting that uploading as unsigned integer is faster than bytes ... but get the concepts behind all of this.

Not too much to say, except lightmaps certainly can be a point of contention in rendering speed.

I like the in-depth hardware oriented performance analysis of this.

I will certainly be curious to play around with on the 3 or 4 Intel video equipped machines around to see the extent that frame per second improves (one includes my Mac Mini which has Intel Video).

[And maybe this stuff makes the FitzQuake renderer perform on par with some of the other engines in heavy dynamic lighting situations.]

More stuff of substance to experiment with

[mh]

It's not the unsigned integer so much as the "_REV" part that's crucial here. The way I figure it, this is acting as a hint to the driver that "the data is already laid out in the format you prefer to use, so there's no need to send it through a slow path; just take it direct instead".

This is only really important for Intels that have hardware T&L - say, the 965 onwards; it seems as though earlier generations are more tolerant.

[mh]

[ceriux]

[leileilol]

[metlslime]

[ceriux]

[metlslime]

Thanks for this research. I haven't implemented these yet but I read through the diffs; pretty straightforward stuff.

Notes/questions:

1. While you need version 1.2 for GL_BGRA to be a core feature, it seems you could also check for GL_EXT_bgra, which seems to have virtually 100% support (even among version 1.1 drivers) according to (which you linked recently)

2. I assume the same changes would speed up texture loading at map init too, have you tried that?

3. I also wonder if this would be faster for downloading images for screenshots or the imagedump command. (Since TGAs are BGR anyway, it would at least save CPU time.)

[mh]

[szo]

[mh]

[revelator]

[mh]

Just resurrecting this old one regarding the endianness issue mentioned by szo.

The GL spec (page 97, 1.2.1 version) clearly states which bits are assigned to which components for the UNSIGNED_INT_8_8_8_8_REV type so endianness is basically not an issue - 4th component goes in bits 31-24, 3rd in 23-16, 2nd in 15-8 and 1st in 7-0 and if an implementation does otherwise then it's non-conformant.

Where it would be an issue is if you used unsigned int * for your source data type, but because Tex(Sub)Image takes a GLvoid * parameter for data you can still use byte * even with this type and satisfy all requirements.