🔒 Locked

Texture uploading

Started by XiotexStudios Jul 14, 2006 at 4:05 AM 2 replies 750+ views

Original Post

Jul 14, 2006 at 4:05 AM

I have this crazy idea for an effect. Said effect would be extremely easy to do in a shader. Unfortunately target hardware doesn't have shaders (boo hiss!) so looks like if I am going to do effect its going to be by cpu and uploaded each frame. Anybody got some stats on the kind of throughput I can expect with this crazy scheme? My chain will be to triple buffer a texture and lock the relevant one per frame and fill it with new data. Triple buffer cause I hope to avoid causing a flush on the gfx card - or would I be better to create a new texture each time... decisions, decisions... Anyway, the kind of stats I am looking for is optimal size - how big can I go before I begin to cripple the driver/card too much?

Evil Steve

Jul 14, 2006 at 6:20 AM

Depends on the card really, and the connection (AGP / PCI-Express). Just make sure you do a read-only lock. You should be using a dynamic texture (obviously), but it can help to double or tripple them as you suggested.
If the target hardware doesn't support shaders, I'd guess that you're not going to be able to upload too much though. Also remember that the larger the texture, the more time will be spent filling it, so you may become CPU bound.

XiotexStudios

Jul 14, 2006 at 6:24 AM

read-only lock? I am going to be writing to the texture.

Basically, I want to do an effect similar to pertubation but on a shaderless card.

However, sitting back and thinking about it I remember the dot3 bumpmapping examples in the DX8 SDK - it wont be as pronounced as I would like but it would do it!

Nik02

Jul 14, 2006 at 6:26 AM

It is best to profile the uploading speed by using test hardware close to your minimum target configuration, by using a "real-world" usage scenario - that is, running your engine as if it were running the final game - and then determine the size/performance balance based on your framerate target.

EDIT: Geforce 2-class hardware copes with Dot3 operations just fine, in addition to being relatively fast with them as compared to plain texture reads.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.