Highly experimental windows builds

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
User avatar
Ricochet
Round Winner
Posts: 359
Joined: Tue Jun 06, 2006 2:31 pm
Location: United Kingdom
Contact:

Post by Ricochet »

wrtl: still getting really bad fps... Using revision R8355, with all textures turned off, I get less than on the 0.3 beta (from >12 months ago) with all textures on full...

any thoughts?

User avatar
Lackadaisical
Shutout Match Winner
Posts: 822
Joined: Sun Dec 21, 2003 4:58 pm
Location: Amsterdam, Netherlands
Contact:

Post by Lackadaisical »

There's a freeze which happens occasionally for me and appearantly for Monkey as well. It always happens between rounds and i think it's because i'm either pagingup/down or because i'm glancing. Anyway, here's a recording (It happens after the first round ended, but the round is kinda long, and im pressing pageup/down and my glancing keys repeatedly, version r8355):

edit: yeah, it's definatly the glancing keys, and i've tried it in both windowed and full screen mode.
edit: monkey might have a different problem..
Attachments
ArmagetronAdvancedDebugRecording.zip
this is actually zipped
(339.8 KiB) Downloaded 128 times

User avatar
Z-Man
God & Project Admin
Posts: 11302
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Hmm, when playing this back on a Linux binary from the same source, I get a "recording ends here, prepare for a crash" message, but then nothing bad happens, the game runs on (with all cycles just going straight, of course). What happens when you play back the recording on Windows?

User avatar
Lackadaisical
Shutout Match Winner
Posts: 822
Joined: Sun Dec 21, 2003 4:58 pm
Location: Amsterdam, Netherlands
Contact:

Post by Lackadaisical »

The screen freezes right when it says 'Go! round ...', and I have to close it through the taskbar (which is the same as when I was playing.)

Monkey
Match Winner
Posts: 725
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Post by Monkey »

AdyLucifer wrote:i found out that disabling wall textures increases the fps by 20-50%
Z-Man wrote:Aha. There is no reason at all this should happen, ever since the early days of 3d cards, texturing has absolutely no speed penalty. I'd attempt a driver reinstallation at this point.
Jonathan wrote:Mipmapping is free on hardware but the bad locality of no mipmapping isn't. Bilinear is no slower than nearest on hardware so go for nicer filtering.
Jonathan wrote:Trilinear DOES slow things down.
Z-Man is saying no penalty and Jonathan is saying penalty only for trilinear?
Is OFF better than any type of texture or just the same?
Should I be able to have wall and objects textures on any setting with no penalty to performance (I have a modernish 3D card, ATI Radeon 9200)?
/me is confused. Educate me please.
Playing since December 2006

epsy
Adjust Outside Corner Grinder
Posts: 2006
Joined: Tue Nov 07, 2006 6:02 pm
Location: paris
Contact:

Post by epsy »

actually i think texture filtering depends on your gfx
on mine(i915) trilinear filtering is way faster than bilinear

User avatar
Jonathan
A Brave Victim
Posts: 3392
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

Mipmap trilinear vs. MIPMAP bilinear? Would be strange if the latter is slower. Trilinear uses twice as many samples which can potentially use twice as many texture filtering units and twice as much memory bandwidth. Certainly no less.

Off could be slightly faster. Texturing itself is indeed free on hardware, but memory bandwidth can become a bottleneck. Off also saves some state changes, but see if you can actually notice that.

I think a Radeon 9200 can do walls + objects on trilinear with practically no slowdown. But watch out with the high rim, if you use it, and the floor would also hit performance on trilinear. Note that there's little overdraw, so you should be fine if your GPU has some fillrate/memory reserves (any reasonably modern GPU should do). Just see what works for you.
ˌɑrməˈɡɛˌtrɑn

User avatar
Z-Man
God & Project Admin
Posts: 11302
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

The "no penalty for texturing" is for old accelerator cards, actually. I know for a fact that a Voodoo 2 card would fill all polygons at the same speed, whether they were flat, shaded, textured (single texture trilinear filtered or dual texture bilinear filtered).

Nowadays, things have gotten slightly more complicated. Those old cards didn't have caches, they'd just operate directly on their small and fast video memory. That's why lookups had a constant speed. Modern cards have an abundance of shader units that all want to get fed over the same narrow bus with data from the texture memory, and even the fastest memory can't keep up with the total demand. So they cache memory access.

What you have to know then is that caches don't work on individual tex(ture pix)els; that would be a waste. They operate on pixel blocks (the Wii GPU uses 4x4 blocks, for example). The reason for this layout is simple: for bilinear filtering, you need a 2x2 block of texels for each rendered pixel anyway, so chances are good those can all be fetched with a single read, maybe two reads, and only with a 1/16 chance with four reads of a cache line.

Chances are, too, that the next pixel you need blended can reuse the data you just fetched. But: only if the current scale factor is not too minimizing. If each screen pixel would contain more than 16 texels if rendered exactly, then each rendered pixel will need new data from main memory to be fetched. This situation occurs if you disable mipmapping.

So currently, on pretty much all cards that are in use, mipmapping improves performance. Current shader units also perform the bilinear filtering without speed penalty, and it only causes a marginal increase in memory bandwidth usage, so you should not notice a change from nontextured rendering to bilinear mipmapped texturing.

Trilinear filtering, in most cases, definitely increases the memory bandwidth usage. So it can be slower by up to 50% than bilinear filtering in worst case polygon orientation, if memory bandwidth is the bottleneck. But I doubt memory bandwidth is a problem in Armagetron: we're only using single texturing, and cards are optimized for around 8 texture layers.

User avatar
Jonathan
A Brave Victim
Posts: 3392
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

Z-Man wrote:Chances are, too, that the next pixel you need blended can reuse the data you just fetched. But: only if the current scale factor is not too minimizing. If each screen pixel would contain more than 16 texels if rendered exactly, then each rendered pixel will need new data from main memory to be fetched. This situation occurs if you disable mipmapping.
Also, before you get there memory demands increase gradually. Mipmapping ensures it's limited at about 1 (bilinear) or 2 (trilinear) texels per pixel on average.
z-man wrote:Trilinear filtering, in most cases, definitely increases the memory bandwidth usage. So it can be slower by up to 50% than bilinear filtering in worst case polygon orientation, if memory bandwidth is the bottleneck. But I doubt memory bandwidth is a problem in Armagetron: we're only using single texturing, and cards are optimized for around 8 texture layers.
The Mobility Radeon 9600 was definitely hitting memory limits with 32-bit trilinear. Adding more textures only made it slower and less efficient (but more efficient than doing several passes, fortunately).
ˌɑrməˈɡɛˌtrɑn

Post Reply