timer.device:GetSysTime:UNIT_VBLANK not recognized

[VladR]

I'm trying to do some profiling of my 3D engine and need a detailed breakdown of all pipeline stages.


For that, historically, on Jaguar, I've used a method of drawing over 1,000 vblanks (16.6 seconds) which is more than enough precision for my purposes. Unlike cycle counters, this approach shows a stable&reliable value across a gameplay-significant portion of time, so all the system-level spikes are averaged out.


On Jaguar, I already had an interrupt, where I simply incremented FrameCounter variable.


At this moment, I don't wish to indulge in Amiga's idiosyncrasies in IRQ handling, so I figured using timer.device should be safer and easier, given that I already have a working OS calls routines. Right?




Well, it wasn't, but after about a day of troubleshooting, I got the GetSysTime initialized and now I have a GetSysTime () working.


However, changing UNIT_MICROHZ into UNIT_VBLANK during initialization didn't accomplish anything. In fact, nothing changed and the timeval struct (which the docs say is still to be used for UNIT_VBLANK) still returns elapsed time in seconds.




As per the documentation, UNIT_VBLANK (register d0 prior to jsr _LVOOpenDevice (a6) ) doesn't need my own IRQ but relies on power supply strobe mechanism. Might not be implemented on WinUAE, perhaps ?




Potential workarounds, sorted by level of WTF-ness:
1. Utterly Ridiculous: Screw timer.device and implement IRQ (FrameCounter++)
2. Stupidly Ridiculous: Convert timeval.seconds/microseconds into vblank count
3. Plain Ridiculous: Start sending builds for external testing to see if it maybe works on real HW already


Is there anything I have apparently missed in docs with regards to UNIT_VBLANK behavior/set-up ? It appears that I should just do move.l #UNIT_VBLANK,d0 prior to jsr _LVOOpenDevice(a6)


Maybe I need to enable something in the WinUAE ?

[meynaf]

IIRC the UNIT settings do not change the unit used by the result, but only the accuracy.
Winuae certainly has nothing to do with that.

Your solution #1 looks quite acceptable.
There is no need to do direct interrupt handling though, just using AddIntServer to add your code to the system's vblank server list is enough.

[VladR]

Originally Posted by meynaf

IIRC the UNIT settings do not change the unit used by the result, but only the accuracy.
Winuae certainly has nothing to do with that.

So, the GetSysTime can really only return time in a single supported unit, despite timer supporting 5 units ? It certainly doesn't mention that in the docs.


That sucks, but I couldn't have known. At least I know I didn't do anything wrong.


The docs say the following:

UNIT_VBLANK


This unit uses a strobe from the power supply to keep track of its time or the "E" clock on machines without power supply strobes. It is very stable over time, but only has a resolution of that of the vertical blank interrupt. This unit is very cheap to use, and should be used by those who are waiting for long periods of time (typically 1/2 second or more). This unit uses a timeval in its timerequest

So, there is no reason to believe it wouldn't return number of elapsed vblanks in the timeval.


But, at least I can move on and stop burning time on this thing. Thanks !

[grond]

Power supply strobes are only implemented in big box Amigas and thus in the vast minority of Amigas. Implementing a VBL server and adding it is a matter of a few lines of code and best suited for what you want.

[VladR]

I'm sure it is. But from experience with interrupts across about ~dozen platforms, I'd like to avoid a scenario where I have to remotely debug why IRQ on some end-user's box is crashing/hanging and burning a week on that.

I'm sure there's 10+ scenarios where a certain combo of Amiga OS/libraries/versions/drivers will result in non-standard IRQ behavior and my routine will either not get called in the chain, or I will have to hack it for a specific remote use case or something entirely different will happen. After burning a week on debugging it...

It even looks like I might get away without using IRQ for audio as I'll be using final 44.1kHz mix and no real-time mixer will be thus needed.

Regardless, it only took about an hour to add the functionality of waiting till the microseconds are zero and auto-normalizing the timestamp at the start-up, so I'm now working only with relative values (of seconds), starting nice and clean from 0.

So, after each benchmark test, I now have two values (sec,miccrosec) to store instead of one (vblCount), so it's not a huge deal - though having just a single value would have been preferred.

[grond]

Vertical blanking interrupts are a fundamental mechanism of Amigas and there are no problems with it across the entire platform except for NTSC vs. PAL or 60 Hz vs. 50 Hz which can be dealt with easily. Installing an VBLirq is as easy as calling the corresponding OS function.

[Thomas Richter]

Originally Posted by kamelito

However, changing UNIT_MICROHZ into UNIT_VBLANK during initialization didn't accomplish anything. In fact, nothing changed and the timeval struct (which the docs say is still to be used for UNIT_VBLANK) still returns elapsed time in seconds.

That is the purpose of the call, the time unit is, ehem, device unit independent.

Originally Posted by kamelito

As per the documentation, UNIT_VBLANK (register d0 prior to jsr _LVOOpenDevice (a6) ) doesn't need my own IRQ but relies on power supply strobe mechanism. Might not be implemented on WinUAE, perhaps ?

No, it means that it is very properly implemented. UNIT_VBLANK can be driven by two sources, the power supply strobe (prefered, as very stable and not monitor dependent) or the vertical blank (to be avoided, as less stable and monitor dependent).

Originally Posted by kamelito

Potential workarounds, sorted by level of WTF-ness:
1. Utterly Ridiculous: Screw timer.device and implement IRQ (FrameCounter++)

If you need a frame counter, and not a time, then implement a frame counter. The timer device gives you a time basis, not a frame basis. The latter is monitor dependent, the time is not.

Originally Posted by kamelito

2. Stupidly Ridiculous: Convert timeval.seconds/microseconds into vblank count

If you need a vblank count, then this is not a robust alternative as the time basis is not necessarily related to the monitor.

Originally Posted by kamelito

3. Plain Ridiculous: Start sending builds for external testing to see if it maybe works on real HW already

That is hardware dependent, as already said by others. The time source of the VBLANK unit differs upon models. It is a (coarse) time source, not a frame synchronization mechanism.

[VladR]

How exactly did kamelito get into your copy-pasted quote header ?

[grond]

Originally Posted by Thomas Richter

the vertical blank (to be avoided, as less stable and monitor dependent).

When you say "monitor dependent", you mean "screenmode dependent", right?