[MrC]

hi

i am trying to write a visualisation plugin but even with an empty render function i only get 25fps. i tracked this down to a sleep(16) call in cguiwindowvisualisation::render().

is it needed and if so how can i get my vis running at full frame rate?

cheers

mrc

[Butcher]

yes it's needed so the audio codecs have enough cpu to process the audio.

[Gamester17]

@Butcher, could the gpu be used in any (better) way to help process visualization rendering? (goom is also running at a very low resolution)

[Butcher]

depends how the vis is coded. generally people coding visualisations for xbox should be looking to rely heavily on the gpu not the cpu. the ideal is to have the vis run on the gpu almost exclusively and just use the cpu for audio steam decode and ffts for sprectrum analysis.

btw sleep(16) gives a maximum framerate of 62.5 fps, if you're only getting 25 with an empty render function then something is using a lot fo cpu.

[Gamester17]

i found this browsing nvidia's developers website, not sure if it can be used for this but here you go anyway:

fast math routines
http://developer.nvidia.com/object/fast_...tines.html

entire nvidia directx8 sdk 5.0
http://developer.nvidia.com/object/nvidia_dx8_sdk.html

general-purpose computation using graphics hardware
http://www.gpgpu.org/

microsoft directx reference for developers
http://msdn.microsoft.com/library....8000410

nvidia audio sdk
http://developer.nvidia.com/object/nvidi...o_sdk.html

nvidia audio - generate compelling audio effects.
http://developer.nvidia.com/object/docs_audio.html

nvidia developers websites:
http://developer.nvidia.com
http://nvdeveloper.nvidia.com

[MrC]

thanks for your replies.

i did the following test in pal with no vis and no music playing.

on the main menu with nothing going on it runs at 50fps.
if i add a sleep(16) to capplication::render() the frame rate drops to 25fps.

because there is a blockuntilverticalblank() it is never going to run faster than 50fps. sleep(16) is over half a frame which explains why the frame rate halfs.

does the audio codec really need half a frame to do its stuff?

surely this can't be right? most xbox games play a wma at the same time as running the whole game at 50fps!

cheers

mrc

[Butcher]

xbox games don't play wma... they play either uncompressed wavs or adpcm wavs which are decoded in hardware. we do software decoding of things like wma, mp3 and such, which a game wouldn't. still the sleep can probably be reduced to around 8-10 ms.

[MrC]

so how do they play user soundtracks then?

[Mezz]

i'm just not buying this.

i'm going to refute a lot of what's been said because it's just incorrect.

firstly, on "xbox games don't play wma"
yes, they do. it's a supported and recommended format for music in xbox games. i can accept they aren't using wma for sound effects (gunshots etc.) but for music there is no reason not to, especially since there is support in the title libraries for them. i know several games, including the one i am working on which use wma.

secondly, "it's needed so the audio codecs have enough cpu to process the audio".
i've run winamp on a 450mhz pc in the background while playing quake3 on a geforce1 and got great fps, how come these audio codecs need ~16ms to do their processing in the foreground on a faster, dedicated processor.

thirdly, "btw sleep(16) gives a maximum framerate of 62.5 fps, if you're only getting 25 with an empty render function then something is using a lot fo cpu"

yes, there is and it's the blockuntilverticalblank() call.
this is suicide in production code, and will lock the framerate in a very nasty fashion, at least use the present parameters (presentation interveral one or imediate) if you're going to do this kind of debauchery, or, even better, allow the visualisation that is running to say "i want immediate presentation" or "i want you to vsync this".

i don't understand why you have a vblank and a sleep() call, one or the other should suffice if you really want to starve rendering for audio processing (which you shouldn't because the system ought to manage the threads well enough anyway).

sorry to rant, but this stuff needs sorting out or interest isn't going to be perked because people aren't going to write a vis. when the performance is in such a bad state for them to start with.

cheers,

-mezz

edit: typos

[Frodo]

cool down a bit, and i'll try to explain it

first this blockuntilverticalblank() call.
this is actually needed, not for music offcourse, but for playing movies. the updateoverlay() we are using on the yuy2 overlay textures is done immediately.
without the blockuntilverticalblank() call this would result in much tearing effects when watching a movie. in any case you always wanna lock the video with the vertical sync to avoid these tearing effects. thats what this call does

also please remember that pal/ntsc means you always get 25/30 fps outputed to the television. so its absolutely nonsense to run the gui (or visualisation) on 300 fps. in the end just 25/30 fps will be shown on your tv anyway

btw i'm talking about 25/30 fps progressive cause tv's are interlaced you'll see 50/60 fps interlaced

now the sleep() thing
there's absolutely no need for this call.
so why is it here you may ask? well the problem is the spectrum.vis
if you remove the sleep() call it will be very very ugly
dont ask me why, i didnt write the spectrum.vis.
with the sleep() its ok. i agree this is an ugly hack and it should be fixed in the spectrum.vis

frodo

[Mezz]

ok, sounds reasonable.

so, is there any chance of the following:

1) the sleep() hack being fixed in the spectrum vis.?

2) can we not have an

if(playingvideo)
  verticleblank();
else
  don't;

would this not solve the issue, or, as i said, the option to do it/not do it (you could do this with an update of present parameters and then a resetdevice() call couldn't you?).

i know that in the end your maximum refresh will be 50/60 anyway but i just don't like it when things sit and spin for no reason

-mezz

[Butcher]

wma was not a good example, but regardless, wma is not all we support. there are other codecs in use that take more cpu than the wma decoder. plus games don't stream audio off the network, if you have some network lag then the audio codec will have to refill the buffer quickly which takes a reasonable chunk of cpu. also games don't have to run a ftp server, python scripting, http server etc. in the background. i have no idea which codec uses the most cpu off hand, the mod player used to kill the cpu with just the audio stream running let alone a vis before i re-implemented it in hardware, so you can't assume audio codecs are very cheap.

i don't see why blockuntilverticalblank is that bad. if you sleep for 16ms then block while running at 50 hz it will block for 4ms then go back to the sleep (assuming no other code running). you'll get 50fps. 60hz is a bit less clear cut as the sleep is almost the same as the frame time, it would depend how much the other threads are doing. in any event the present params are setup for vsync, so i'm not sure why we have a blockuntilverticalblank at all.

instead of ranting how about you fix it? the point of open source is that anyone can fix it (given knowledge and ability and you certainly claim to have both). so instead of moaning about it, go and sort it out. personally i haven't had a chance to look at the vis stuff at all (other than fixing a memory leak in goom), and i'm not likely to get round to improving this sort of thing for some time (weeks rather than days). so if you want something done about it, go do it.

edit: just saw frodo's post...
we don't need the waitforverticalblank any more as overlays are gone for movie playback. i switched the presentation parameters to use vsync to prevent tearing.
i don't really see the milage in resetting the device for the vis just to avoid having a sleep or spin in the loop. personally i'd prefer a sleep as it means you can use things like the ftp server while the vis is running without getting low performance.

[Mezz]

ok, well let me start by offering an apology, i didn't mean to come across as harsh i just see so much programming debauchery and incorrect information during my day job that i was frustrated by the non-obvious reasons for some of the aformentioned code present in xmbc.

i didn't want to just dive into source code and change something without first knowing why it was there in the first place. i could've changed it and just broken something else, which wouldn't have helped anybody. it seems from what you (butcher) and frodo were saying originally, the vblank and sleep(16) were required. now, i'm getting conflicting information and i'm not entirely sure what is the correct course of action.

i believe the vblank and sleep(16) combination was causing the 25fps slowdown - if you recall mrc's post above, the menu runs at 50fps, this goes through the vblank call. if you add a sleep(16) to this, it drops to 25fps. if you then remove the vblank and *leave in* the sleep(16) call, it runs ~35fps.
i just verified this myself (on a greenie).

so, to conclude i have a couple of points/questions.

1) are both a vsync and a sleep() required?
from the docs, it seems like a blockuntilverticalblank() call yields so other threads can do processing, if this is the case, it seems like a sleep() would be redundant, and vice-versa.

2) using the ftp server while the vis is running is a compelling argument - the sleep() would handle this, but i don't think you need a vsync to double-enforce that, or have i missed something?

3) a sleep(10) if you think that's enough, and without a vblank runs around 45fps. this might be a reasonable compromise between graphics and other tasks needed, but i'm not fully grokked on the other code so i can't say for certain.

anyhow, let me know if you think any of that is good/bad/whatever before i go into source code and break anything

cheers,

-mezz

[Butcher]

assuming blockuntilverticalblank actually yields (i thought the docs indicated it, but with a name like that it's hard to say for sure), that should do the job. i'm not sure how that will interact with the presentation interval (which was immediate, but as of yesterday is one). as i've eliminted overlays the wait for blank shouldn't be neccessary for them.
my personal preference is either blockuntilverticalblank or to do something similar to what the mod player does - process the audio and vis for a frame then sleep for the remaining time until the next frame is ready. it requires timing the processing, but that's not too difficult. an example of this is in xbmc\xbmc\lib\mikxbox\source\drivers\drv_xbox.cpp:

int proc = (int)(100000 * (time.quadpart - lastupdate.quadpart) / counterfreq.quadpart);
// conservative guess of time to sleep - this seems to work quite well though it probably wastes a bit of cpu
q = (1000*125)/(md_bpm*50) - (proc + 99) / 100 - 1;

here proc is the number of 10us intervals since the last update - effectively the processing time for a frame. q is then the sleep quantum in ms. (1000*125)/(md_bpm*50) gives the frame time - unfortunately it varies for mods, this would just be 20 or 16 for a vis. the sleep is usually betwen 0.5 and 1.8ms too short for the mod frame rate, in the mod player i sync by busy waiting, the vis renderer could just ignore the difference or wait for vsync.

[pike]

@MrC, been some changes lately, u should try current cvs for speed