PDA

View Full Version : Physical reason of texture size limitation



Hybris
05-31-2007, 12:18 PM
Hi,
does somebody know why texture size is limited to 4096 or a similar small number on current hardware?
Does the texture addressing part of the hardware is expensive and why?

Thanks

ZbuffeR
05-31-2007, 03:14 PM
4096*4096 is small ???
Come on ... back in the 3dfx days it was 256*256 max ... :D
And please remind me the point of having textures with more than twice the resolution of a HD screen ? ... :cool:

Ok getting serious now.

The real question is "why 3d card makers did not switched already to fully virtualized texture memory".
I make a guess : laziness. No strong need in games, and implementation of a very fast, deterministic virtualized memory texture sampler would cost money.
It is not like "FSAA", "higher FPS", which are all incremental.
A game taking advantage of "infinite textures" with new hardware would look blurry on all previous generation cards. Or a workaround is developed, so no need for this new hardware.


John Carmack posted an interesting (and long) article on its .plan dated 3/7/00 : <a href="http://www.bluesnews.com/cgi-bin/finger.pl?id=1&time=20000429013039" target="_blank">
Virtualized video card local memory is The Right Thing</a> (scroll down a lot).
(Funny to see that we already have 4*32 floating point textures and frame buffers, but not virtualized texture memory ...)

Even if the solution is not in hardware, it is possible to do texture virtualization yourself (http://en.wikipedia.org/wiki/MegaTexture) .

Korval
05-31-2007, 04:26 PM
The real question is "why 3d card makers did not switched already to fully virtualized texture memory".Actually, that's an entirely different question.

The reason for having a max texture size is all about complexity of the texture fetch unit. With a texture fetch unit of a specific size, you can optimize the number of bits used in the texture unit.

4096 is 2^12. Add in, say, 8 bits for sub-pixel accuracy, and you have 2^20 fixed-point. A far cry from a full IEEE 32-bit float, with much simpler blending and interpolating logic.


I make a guess : laziness.Or, maybe, "It's really hard to do and be performant at the same time." Shocking though it may be, Carmack is not a hardware maker. He does not make graphics cards; he's a coder. He may want to have this, he may even call it "the right thing". But that doesn't mean it suddenly manifests itself in reality.


It is not like "FSAA", "higher FPS", which are all incremental.Um, FSAA is hardly incremental. Particularly with regard to the various technologies that have made anti-aliasing actually performant (multi-sample, rotated grid sampling, etc).

k_szczech
06-01-2007, 03:01 AM
I could really use very large 1D textures.
Imagine the sound engine you can implement on GPU :)
Using cubemaps, environment mapping, specular lighting and shadowmaps you can simulate acoustics in realtime. Material properties would become acoustic properties of the surface.
And linear filtering of 1D texture would increase sound quality when using doppler effect or other sound frequency modificators.
On SM2.0 and 3.0 hardware this would require storing sound in 2D textures, on SM4.0 we can use large textures as arrays but I think classic 1D texture would be better in this case.

Too bad soundcards are so far behind.

Yeah, GPU's are not for sound so you may find it a bad example but I think there are enough cool things you can do with large 1D textures or 2D textures with one of dimensions being large.

Bruce Merry
06-01-2007, 04:31 AM
Originally posted by k_szczech:
I could really use very large 1D textures.
Your wish has been granted: GL_EXT_texture_buffer_object (http://www.opengl.org/registry/specs/EXT/texture_buffer_object.txt) .
On the other hand, you will need a DX10-level card, and last time I looked NVIDIA didn't have driver support.

k_szczech
06-01-2007, 07:23 AM
Your wish has been granted: GL_EXT_texture_buffer_objectYes, that's what I had in mind when I mentioned large textures on SM4.0 hardware.

I've been actually thinking of implementing such GPU-accelerated sound engine for my framework and I wouldn't like it to require SM4.0 hardware as minimum ;)
On the other hand - I won't do it anytime soon (unless there's someone interested in paying for such technology :D ).

Ok, but I'm getting off topic here.

ZbuffeR
06-01-2007, 10:03 AM
@Korval:

Or, maybe, "It's really hard to do and be performant at the same time." Come on, that is exactly what I wrote :) "implementation of a very fast, deterministic virtualized memory texture sampler would cost money".

Jan
06-01-2007, 12:17 PM
@k_szczech: May i ask, what you are doing, that you need such a sophisticated sound engine? Or is it just a special interest of you?

k_szczech
06-01-2007, 05:20 PM
May i ask, what you are doing, that you need such a sophisticated sound engine?You may ask...

Ok, seriously now: I don't need such engine for anything particular. I just thought it would be cool.
I've tried OpenAL, Direct Sound and BASS so far. I used OpenAL in my game at first but due to crashes caused by bug in OpenAL implementation I finally switched to portaudio and my own 3D sound engine.

I really think that all current sound libraries lack some features. Not much has changed during last 10 years.
Think of sound delay for distant explosions or sound heard through wall for example.

The implementation of such sound engine would be quite simple actually. I think it would be about two weeks of honest work for basic version with realtime acoustics. I'll have to think of it in later version of my framework. Right now I want to finish first release and I really cannot find enough time for it - too much chaos at work currently (and I don't mean just this week or month).

KreK
06-02-2007, 04:59 AM
Great, first physics and now sounds coming from your gfx card. I wonder if we'll have a Linux for GPU in a few years. Jokes aside, I think your idea sounds great (no pun intended). I hope you'll release more info if it ever becomes reality.

Brolingstanz
06-02-2007, 05:46 AM
Jokes aside, I think your idea sounds great (no pun intended).I need more cowbell.

knackered
06-02-2007, 06:43 AM
if you've got spare gpu cycles to do audio and physics, your graphics won't be bleeding edge. Pat yourself on the back for being clever as everyone else wonders why your graphics look dated.

zeoverlord
06-02-2007, 07:40 AM
Originally posted by KreK:
I wonder if we'll have a Linux for GPU in a few years. Jokes asideNo joke, i read somewhere that the GF8800 is so programmable internally that in one or two generations from now a GPU might actually be able to run an os, and while it's not an effective CPU it will at least be possible.
About the other things, yea, from what i heard both ati and nvidia cards will in the future have small sound processors built in (for better HDMI support) and maybe even physics chips, so maybe the GF11800 will be able to actually run a game without ever using the CPU or ram for anything other than key input, loading and setting things up, we are not that far off today.

k_szczech
06-03-2007, 04:07 AM
if you've got spare gpu cycles to do audio and physics, your graphics won't be bleeding edgeJust think of how much GPU cycles will sound actually steal?
Averagely that's just rendering to 441x100 texture once per second. Yes, it's multipass (one pass for each sound you hear at the moment), but how many sounds you actually hear? Most games support 16-32 simultaneous sounds by default.
I guess "wasting" 0.5%-1.5% of GPU power would in fact make grapthics not to be truly bleeding edge, but I don't believe gamers have such sophisticated performance measurements in their eyes to see the difference.
And if you sacrifice another 1% of GPU performance for realtime acoustics they will start to hear the difference.

So actually making realtime reflections on car, updated once every 5 frames is way more costly.
Rendering to one small shadowmap once per frame is way more costly.

The only performance bottleneck would be retrieving about 44100*b*c bytes per second by the means of glGetTexImage (b-bytes per channel, c-channels).
For standard sound it's 44100*2*2 = 176400 bytes per second.
glGetTexImage works pretty well. Unlike glReadPixels it doesn't work on active framebuffer so there is no stall.

The only drawback of this approach is that when someone will have severe performance problems he will also experience sound stalls, but I consider it forgiveable under such circumstances and perhaps even better (if performance is low we don't spend that valuable computing power on trying to playback sound in realtime).

Ok, this is actually off topic and I don't want to discuss it right now since I don't have time to implement it anyway.

-I want to buy a computer
-What kind of computer?
-GeForce 10