Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Leif Delgass <ldelgass@re...>  20020327 21:01:10

On Wed, 27 Mar 2002, Alexander Stohr wrote: > > So we'd use > > mach64Screen>cpp for the calculation instead of a fixed 4 > > bytes/texel? > > Then the comparison would be: > > > > if mach64Screen>texSize[0] >= > > 2 * mach64Screen>cpp * 1024 * 1024, then MaxTextureLevels = 11 > > else if mach64Screen>texSize[0] >= > > 2 * mach64Screen>cpp * 512 * 512 , then MaxTextureLevels = 10 > > else MaxTextureLevels = 9 (256x256) > > > > This should apply to Rage128 and Radeon as well. Am I > > missing something here? > > Yes, if you have a Radeon with i.e. 128 MB then you might want to > use even bigger textures or higher max levels, as long as the > renderer can handle them. > > Some sort of iteration or loop design might turn out to be the best. > At least you can specify the lower and upper limits much easier then. > > Regards, AlexS. Yes, for Radeon you can go with a larger texture (2048x2048 looks like the max from the code, I don't have Radeon specs), I was thinking in terms of mach64 which has a max. size of 1024x1024. But do you see any problem with the basic idea in terms of using the screen bit depth? Also, the first '2' should probably be MaxTextureUnits for cards that have more than two texture units implemented, right?  Leif Delgass http://www.retinalburn.net 
From: Leif Delgass <ldelgass@re...>  20020327 22:01:49

On Wed, 27 Mar 2002, Daryll Strauss wrote: > On Wed, Mar 27, 2002 at 04:00:55PM 0500, Leif Delgass wrote: > > On Wed, 27 Mar 2002, Alexander Stohr wrote: > > > > So we'd use > > > > mach64Screen>cpp for the calculation instead of a fixed 4 > > > > bytes/texel? > > > > Then the comparison would be: > > > > > > > > if mach64Screen>texSize[0] >= > > > > 2 * mach64Screen>cpp * 1024 * 1024, then MaxTextureLevels = 11 > > > > else if mach64Screen>texSize[0] >= > > > > 2 * mach64Screen>cpp * 512 * 512 , then MaxTextureLevels = 10 > > > > else MaxTextureLevels = 9 (256x256) > > > > > > > > This should apply to Rage128 and Radeon as well. Am I > > > > missing something here? > > > > > > Yes, if you have a Radeon with i.e. 128 MB then you might want to > > > use even bigger textures or higher max levels, as long as the > > > renderer can handle them. > > > > > > Some sort of iteration or loop design might turn out to be the best. > > > At least you can specify the lower and upper limits much easier then. > > > > > > Regards, AlexS. > > > > Yes, for Radeon you can go with a larger texture (2048x2048 looks like the > > max from the code, I don't have Radeon specs), I was thinking in terms of > > mach64 which has a max. size of 1024x1024. But do you see any problem with > > the basic idea in terms of using the screen bit depth? Also, the first > > '2' should probably be MaxTextureUnits for cards that have more than two > > texture units implemented, right? > > This is all really just a heuristic. It works around a bigger problem > that there's no good way to tell how many textures can fit on the > board. So, these rules favor something like quake wher you want two > textures (in order to multitexture) on the board at the same time and > therefore lies to the application in defining what the maximum texture > size is. > > Unfortunetly, this then breaks apps that require the use of bigger > textures like you saw in the planet screensaver. You can argue that the > planet screensaver should have made smaller textures. Since the app can > query the maximum texture size, but that only works if shrinking texture > map is acceptable for the app. > > If you use the correct hardware maximum texture size, then the problem > is for the app is to determine if it can fit big textures in > memory. There's no good way to query, but an app can test it by trying > to do it at the maxmimum and then step down the texture size until it > reaches one that's fast enough. That's the correct general approach in > any case. > > So, making it 3 for a Radeon because it has 3 texture units isn't more > correct. In fact, I'd argue that breaking your driver so that it is not > capable of doing what the hardware can do is really the wrong solution > overall. One of my apps needs 2k textures, and this heuristic makes the > board nonfunctional for my app. Luckily it's all open source so I can > change it! > > I have no objection to making changes that make specific apps (like > Quake) run faster as long as they don't impact other programs. This is a > case where setting an environment variable like LIBGL_MAX_TEXTURE_SIZE > might make sense or just having LIBGL_I_AM_RUNNING_QUAKE mode. Then it > could throw correctness out the window and go as fast as possible. As > long as it's only on when I ask for it, that's no problem. If I haven't > asked the driver to be broken, I want correct behavior that allows me to > use all of the hardware. > >  Daryll I see what you mean. I noticed that one of the new screensavers (flipscreen3d) wanted to create a 1024x512 mipmap from a screen grab and failed, even though it should work with a single texture. If I set MaxTextureLevels to 11, it works. Perhaps it's better, as you say, to just use the maximum number of levels supported by the card and provide an env var to step it down for apps that try to use the max. size for multitexturing. I'm not really a big fan of having a proliferation of env vars, but I guess it's ok for now. It might be nice to have some sort of configuration file or interface like 3D workstation drivers where you could create application profiles with different settings. I suppose you could accomplish this by creating shell scipt wrappers for your GL apps that export the appropriate env vars.  Leif Delgass http://www.retinalburn.net 
From: Alexander Stohr <AlexanderS@at...>  20020328 01:00:49

> > (This is based on the idea that a full set of mipmaps packs > perfectly to take > > up two times the size of the base texture). That's also > not true for all > > architectures... > > Ok, that explains a bit. However, in some circumstances we > may loose a > level. The mipmaps don't double the size, the only increase > it by 1/3. > Then there are architectures like MGA the can't use all 11 mipmaps. Okay, me was odd. (this always happens when i am thinking with the stomach...) But now i will try to go into deep and get to final formula of (4/3 * Lvl_size) for the maximum of expected pixels in the total amount of data stored in a squared level stack. Further i will point out to the goods and bads of the mentioned bithshift formlua and the alternative method of looping. In the end i will point out to reverse calculation methods and to specific implementations that finally might break or at least complicate the overall systematics of pyramid stack calculations. grafically: n=2 n=1 n=0 #### ## # #### ## #### #### mathematically: level width = 2^n level size = (2^n)*(2^n) = 2^(2*n) size increse ratio per level increment = 4 = (2^(n+1))*(2^(n+1)) / ((2^n)*(2^n)) = (2^(n+1n))*(2^(n+1n)) = (2^1)*(2^1) = 2*2 = 4 summarized size of all levels = sum(x=0, x=n, 2^(2*x) ) (sorry, i dont have the math book handy for solving that here) as the increase ratio is significantly bigger than 2, the sum of n1 will never be bigger than the current level size. So the assumption in the code suggestion with formula 2*(current level size) is okay for now but its not totally accurate as it is. Just let me go on to make it really evident. Lookup table: Lvl_n width size size (hex) accummulated size (hex) acc/sz 0 1 1 1 1 1.0 1 2 4 4 5 1.25 2 4 16 10 15 1.31 3 8 64 40 55 1.328 4 16 256 100 155 5 32 1024 400 555 6 64 4096 1000 1555 ... 7 128 16384 4000 5555 8 256 65536 1 0000 1 5555 9 512 262144 4 0000 5 5555 10 1024 1048576 10 0000 15 5555 11 2048 4194394 40 0000 55 5555 12 4096 16777216 100 0000 155 5555 1.333333313465 ... the +300% increase (or 4* increase) ratio for the size itself is (hopefully) made nicely visible with above. the accummulated size vs. Lvl_size does behave as it is approaching 4/3: accum size / size <= 4/3 so you are still on the safe side if you estimate like this: max accum size = size * 4/3 = size * 1,33333333333 Paranoid people would just add a "+1" after the division, (or much better a "+2" before the division) so that any possible fraction of the division (which will be thrased) gets compensated by rounding the result up to the higher value. A final stack size calculation for a given level depth could look like this: max accum size = (size * 4 + 2)/3 but look what Ian R. said for Lvl_n=10: It would require (0x55555555 >> (32  (2 * 11))) = 1398101 available texels. or more generic It would require (0x55555555 >> (32  (2 * (n+1)))) available texels. This formula Lvl_n would be limited to a maximum of n=15, meaning an amount of 1.431.655.765 Mega Pixel in the total texture level stack. Not really of current practical meaning but if the 4/3 factor hits as well, why should we limit ourselves? The problem with such formulas is that they do cover only a few cases. Textures where both widths are a power of two but are different in power value would require introduce more complexity into such bit shifting shortcuts. Why dont use th empircial counting up method instead? It would only count up for some 10 or 12 cycles on real world systems untill the availabel memory is spent up. If you dont like looping, just multiply the memory amount by a factor 3/4 and get the square root out of it and you got it the reverse way. sqrt calculation isnt that lengthy any more on current ALUs. If a power lies in between the edge wides of the regula texture level stack, then divide by that power first to get the measure of the smaller edge width. Think of this. There are concepts out there where not only the texture size might increase endlessly, but the size is clipped to a specific maximum value whilst the contained image data is bound to a specific viewpoint that is expected to be approached. So even huge image datbases (like earth textures) could be used with hardware texturing units whilst there is no need for huge textur storage. Working this into some looping algorithm would be much easier than into an already complex formula because of the clipper effects could be tuned for any axis and its width separately. think of wide screen video as a rendering goal, its not squared and therefor a non squared texture might give nicer results, if the texture orientation towards the screen is taken into consideration. Regards, AlexS. 
From: <AKarrenbauer@t...>  20020328 01:56:04

Alexander Stohr wrote: > > > > (This is based on the idea that a full set of mipmaps packs > > perfectly to take > > > up two times the size of the base texture). That's also > > not true for all > > > architectures... > > > > Ok, that explains a bit. However, in some circumstances we > > may loose a > > level. The mipmaps don't double the size, the only increase > > it by 1/3. > > Then there are architectures like MGA the can't use all 11 mipmaps. > > Okay, me was odd. > (this always happens when i am thinking with the stomach...) > > But now i will try to go into deep and get to final formula of > (4/3 * Lvl_size) > for the maximum of expected pixels in the total amount of data > stored in a squared level stack. Further i will point out to > the goods and bads of the mentioned bithshift formlua and the > alternative method of looping. In the end i will point out to > reverse calculation methods and to specific implementations > that finally might break or at least complicate the overall > systematics of pyramid stack calculations. > > grafically: > > n=2 n=1 n=0 > #### ## # > #### ## > #### > #### > > mathematically: > level width = 2^n > level size = (2^n)*(2^n) = 2^(2*n) > size increse ratio per level increment = 4 > = (2^(n+1))*(2^(n+1)) / ((2^n)*(2^n)) > = (2^(n+1n))*(2^(n+1n)) > = (2^1)*(2^1) > = 2*2 = 4 > > summarized size of all levels = sum(x=0, x=n, 2^(2*x) ) > (sorry, i dont have the math book handy for solving that here) just FYI the formula is $$ \sum_{k=0}^n q^k = \frac{q^{n+1}1}{q1} $$ in this case $$ \sum_{x=0}^n 2^{2x} = \sum_{x=0}^n 4^x = \frac{4^{n+1}1}{3} $$ and hence the ratio $$ r = \frac{4}{3}  \frac{1}{3 4^n} $$ I hope that this latex code is selfexplaining for those who aren't used to it ;) Regards, Andreas Karrenbauer 
Sign up for the SourceForge newsletter:
No, thanks