Author Topic: Migration to FBO  (Read 29057 times)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #45 on: May 28, 2018, 11:23:32 pm »
Here you are.
« Last Edit: May 29, 2018, 11:12:30 am by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #46 on: May 29, 2018, 09:35:22 am »
Mike

Did you make any change to Mobj.h an Main.cpp into the EXE you sent me (compared to the one attached to post #39) ?

I think we must mimic the use of KillTimer / SetTimer exactly.
With new KillSync / SetSync
(see ProccessCommandline, and other places)

Using a new set of constant
#define SYNC_ON     0
#define SYNC_OFF    1
#define SYNC_BREAK  2

to be used like that
Code: [Select]
void Animate (IN DWORD delay) {
    for (;;) {
        if (gP.syncmode == SYNC_ON) {
            EnterCriticalSection(&gP.cs); // avoid gP.doneRender access conflicts
            if (gP.doneRender) {
                gP.doneRender = FALSE;
                gP.AniTick = GetTickCount();
                PostMessage(gP.hMain, WM_TIMER, IDC_TIMER, 0);
            }
            LeaveCriticalSection(&gP.cs);
            timeBeginPeriod(1); // set wait resolution to 1 msec, else Sleep() will be too rough!
            Sleep(delay); // let loop run at monitor refresh rate plus a few extra FPS for reliable VSYNC
            timeEndPeriod(1); // restore default resolution
        } else if (gP.syncmode == SYNC_BREAK) {
            break;
        } else {
            Sleep(0);
        }
    }
}
« Last Edit: May 29, 2018, 11:01:56 am by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #47 on: May 29, 2018, 11:12:07 am »
Did you make any change to Mobj.h an Main.cpp into the EXE you sent me (compared to the one attached to post #39) ?

None whatever except remming your "gasoline station" and unremming my "pseudo fraps". I'm appending my Main.cpp and mobj.h below just the way they were in my \ObjReader64 subfolder when I sent you the \Release zip.

Below are also the two screenshots I've just taken on my AMD/ATi box that has just one Philips 1680x1050 monitor but two possible resolutions: 59Hz and 75Hz.
« Last Edit: May 29, 2018, 08:13:12 pm by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #48 on: May 29, 2018, 11:57:51 am »
I think we must mimic the use of KillTimer / SetTimer exactly.
With new KillSync / SetSync
(see ProccessCommandline, and other places)

I have absolutely no objections. I am ready to experiment as soon as you send me your new Main.cpp and mobj.h not to overlook some essential points in them that I might not be aware of.

We will also have to deal with main window drag/resize. They are a little rigid now. I think our worker thread loop is still a little too tight.
« Last Edit: May 29, 2018, 11:59:45 am by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #49 on: May 29, 2018, 12:12:09 pm »
Patrice,

Look into my Main.cpp and mobj.h I appended above to be absolutely sure we start off with identical source code before further modifications are introduced.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #50 on: May 29, 2018, 06:25:35 pm »
Mike

Here is my reworked version, this one gives the priority to the user's interaction, to keep the application more responsive.

Thus the speed in turbo mode would be lower than the refresh rate, except if you have a better idea, but preserving usability was my first moto…

New:
case WM_SYNC_NOTIFY:

Added:
I forget to rem out SetProcessorAffinity
« Last Edit: May 29, 2018, 07:27:08 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #51 on: May 29, 2018, 08:47:25 pm »
... this one gives the priority to the user's interaction ...

Patrice,

I understand your motives and in fact the window is now responsive as it used to be, but no, I don't entirely agree to this solution. It loads my quadcore CPU up to 60% (!) of which 50% (t-w-o c-o-r-e-s!!!) are 100% loaded by ObjReader alone!

We must find a way to unload the CPU (in the main message pump, or in the worker thread, or elsewhere) of excessive messages that are causing this horrible mess...
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #52 on: May 29, 2018, 09:56:35 pm »
Patrice,

I regret to say that yours is not a solution. It keeps working even when the animation worker thread is not launched at all. :-[

All timing is still done by the old Windows timer rather than its replacement (the worker thread animation loop), and when the thread isn't running, its otherwise excessive, interfering and meaningless extra refreshes do not overload the renderer any more and the CPU usage drops to its normal ca. 30%, of which ObjReader's contribution is only ca. 25%.

A gl_DrawScene() redraw should normally occur only when there are no other messages pending in the message pump except one most recent WM_TIMER message. This is why the timer message's low priority is so important for the whole engine to work unstressfully on the CPU.

The Animate loop must replace the old Windows timer entirely. Everything that worked based on that timer must now work exclusively based on the Animate loop alone whose messages should have the exact same low priority as the WM_TIMER messages they now replace. The whole purpose of the Animate loop is to be able to do what the Windows timer did but potentially at a much higher frequency that the Windows timer is never able to deliver.

Bottom line is, the old timer must be eliminated from the new code entirely. ::)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #53 on: May 30, 2018, 03:19:04 pm »
Eureka  ;)

Same memory footprint than with the older version, and exclusive use of the new SyncTimer.
« Last Edit: May 30, 2018, 06:04:03 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #54 on: May 31, 2018, 08:24:38 am »
Hi Patrice,

Looks very impressive! :)

I've downloaded the fixes and will come back later with my tests under 7, 8.1, 10 and AMD/ATi.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #55 on: May 31, 2018, 02:05:44 pm »
I have added a new menu "Timing info" command, and did further cleanup of the code + version #2.51.
« Last Edit: May 31, 2018, 02:17:02 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #56 on: May 31, 2018, 05:29:58 pm »
Here is the cleanup version #2.51

Do a WinMerge to see the latest changes.
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #57 on: June 01, 2018, 02:50:21 am »
OK Patrice,

Here come my final fixes for your cleanup. They've been checked under Windows 7 and 10 for nVidia and ATi Radeon at 60 and 75 Hz monitor refresh rates for absolutely identical content and other settings. Note that AMD/ATi's implementation of OpenGL does not support our default half-rate VSYNC wglSwapIntervalEXT(2) = turbo OFF, so it always runs at full monitor rate (currently 60 or 75 Hertz/FPS) regardless of turbo switch setting. The CPU/GPU usage is different on different platforms yet is reasonably low in all test cases.

See my screenshots below. Your FPS counter may deviate and fluctuate slightly from Fraps. This is because i) its implementation is still non-standard, and ii) Fraps averages continuously a few dozens most recent readings and thus eliminates individual FPS spikes that your counter displays instantaneously. I swear the time will come when I finally lay my hands on it again and rework it to be industry standard...

« Last Edit: June 01, 2018, 08:02:37 pm by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1983
    • zapsolution
Re: Migration to FBO
« Reply #58 on: June 01, 2018, 07:15:41 pm »
Quote
Note that AMD/ATi's implementation of OpenGL does not support our default half-rate VSYNC wglSwapIntervalEXT(2) = turbo OFF, so it always runs at full monitor rate (currently 60 or 75 Hertz/FPS) regardless of turbo switch setting.

That's very easy to solve, we can just use the same thing i am doing in BassBox.
aka: Always running at wglSwapIntervalEXT(1), but using in gl_DrawScene something like this in turbo OFF mode:

static long nFlip;
nFlip = !nFlip
if (nFlip) { return; } // turbo OFF mode
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1481
Re: Migration to FBO
« Reply #59 on: June 01, 2018, 07:40:58 pm »
Do you think we really should bother? The overall usage is remarkably low on my AMD/ATi Radeon platform, somewhere on the order of 15 to 20% (some 7 to 8% only for ObjReader proper) even on a dual core CPU, and for both 60Hz and 75Hz refresh rate.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)