OpenGL driver loading abnoxiously slow. (Toshiba laptop L670 2012/Intel/AMD/RadeON)

6 views
Skip to first unread message

skybuck2000

unread,
May 19, 2021, 5:36:25 AMMay 19
to
For some reason on the toshiba laptop from 2012 the opengl driver loads very slowly.

So slow that I believed the application "frooze/hang" but this is not the cause.

Possible causes:

1. I "hacked" the driver version number to try and make Star War Battlefront 2 run.
2. AMD installed a bad driver, or sabotaged the laptop trying to make it run slow.
3. Microsoft fucked up and installed some bad driver to make the laptop run slow.
4. The slow 5200 RPM harddisk is responsible for the slow load. Though 80 MB/sec should be enough ?!

It's suspicious at the very least.

My question is: Is there a programmatic way to tell how long it will take to load the opengl driver ? Is there a way to tell when it's done, besides from ofcourse the rendering suddenly kicking in.

I did a quick google and find two threads that might be of some interesting:

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/loading-an-opengl-installable-client-driver

"
The OpenGL runtime accesses the registry to determine which OpenGL installable client driver (ICD) to load.

To load the OpenGL ICD, the OpenGL runtime:

Determines the name, version, and flags that are associated with the OpenGL ICD by calling the

D3DKMTQueryAdapterInfo function with the KMTQAITYPE_UMOPENGLINFO value set in the Type member of the

D3DKMT_QUERYADAPTERINFO structure that the pData parameter points to.

Checks the version number of the OpenGL ICD that D3DKMTQueryAdapterInfo returns to validate the version

of the OpenGL ICD.

Loads the OpenGL ICD by using the name of the OpenGL ICD.

Initializes access to the OpenGL ICD's functions. Note To obtain a license for the OpenGL ICD

Development Kit, contact the OpenGL Issues team.

To locate the name of the OpenGL ICD, D3DKMTQueryAdapterInfo searches the registry in the following key:
registry

HKLM/System/CurrentControlSet/Control/Class/{Adapter GUID}/0000/

This key also contains the names of the Microsoft Direct3D user-mode display drivers. This key contains four

registry entries for 32-bit Windows Vista display drivers that are used on 32-bit Windows Vista and four

entries for 32-bit Windows Vista display drivers that are used on 64-bit Windows Vista. The following entries

are for 32-bit Windows Vista display drivers that are used on 32-bit Windows Vista:

UserModeDriverName
REG_SZ

The name of the Direct3D user-mode display driver, which is required for the operation of a Direct3D

rendering device regardless of whether the operating system supports an OpenGL ICD.

OpenGLDriverName
REG_SZ

The name of the OpenGL ICD. For example, if the OpenGL ICD is Mydriver.dll, the value of this entry is

Mydriver.dll.

OpenGLVersion
REG_DWORD

The version number of the OpenGL ICD that the OpenGL runtime uses to validate the version of the OpenGL ICD.

OpenGLFlags
REG_DWORD

A flag bitmask. Currently, bit 0 (0x00000001) is set for compatibility. When bit 1 (0x00000002) is set, the

OpenGL runtime does not call the ICD's finish function before the runtime calls the ICD's swap-buffers

function.

The following entries are for 32-bit Windows Vista display drivers that are used on 64-bit Windows Vista:

UserModeDriverNameWow
REG_SZ

The name of the 32-bit Microsoft Direct3D user-mode display driver for 64-bit Windows Vista.

OpenGLDriverNameWow
REG_SZ

The name of the 32-bit OpenGL ICD for 64-bit Windows Vista.

OpenGLVersionWow
REG_DWORD

The version number of the 32-bit OpenGL ICD for 64-bit Windows Vista.

OpenGLFlagsWow
REG_DWORD

A flag bitmask of the 32-bit OpenGL ICD for 64-bit Windows Vista.
"

and this:

https://stackoverflow.com/questions/66089533/how-does-the-opengl-function-loading-mechanism-work

Has anybody ever developed a "loading opengl driver" window/display ?

I could place a label behind the render window and tell the user:

"please wait for the opengl driver to load".

Bye for now,
Skybuck.

skybuck2000

unread,
May 22, 2021, 10:49:35 PMMay 22
to
Here is some more information after running DBG Spider on it:

Short conclusion:

It might be some application code problem, maybe even a Delphi VCL problem, not yet sure.

What the debugger/profiler is showing is something like this:

TOpenGLControl.WMCreate

TControl.WndProc

TWinControl.WndProc

TWinControl.CreateWindowHandle

TWinControl.CreateHandle

TWinControl.UpdateShowing

TWinControl.UpdateControlState

TWinControl.CMVisibleChanged

TControl.Perform

TControl.SetVisible

Classes.StdWndProc

Windows.CreateWindowEx

Game.initialization

Be advise this is not a call stack, but these functions seems to be calling each other.

TOpenGLControl.WMCreate is code I wrote.

What I believe might be happening is that these functions are calling each other repeatedly in some kind of loop or circle.

Surprisingly no stack overflow occurs.

Apperently this loop continues until somehow it gets out of it. Perhaps by a lucky change of events in windows or perhaps some condition is met.

This is my best bet for now.

Bye for now,

Skybuck.

skybuck2000

unread,
May 22, 2021, 11:35:53 PMMay 22
to
My final conclusion for now:

A debug version was tested on windows 7 home edition with ATI/AMD radeon drivers, that were installed multiple times probably by bug in their driver installation program.

This debug version was compiled with delphi community edition 10.3

The same debug version was then zipped up and transmitted to windows 7 ultimate edition on my dreampc and debugged there as well.

The strange behaviour is only witnessed on the laptop with stange ATI/AMD drivers.
The strange behaviour IS GONE on windows 7 ultimate edition with nvidia drivers.

This leads me to some conclusions and hypothesis:

1. Either the driver was "hooked" multiple times into the system or there are multiple drivers running/installed, however only one ati xxx thing seems to be loaded: atigktxx.dll
So hypothesis 1 seems somewhat unlike, no problems are observed in game or in performance.

Which leads me to hypothesis number 2, which I also debugged on top of the laptop itself:
2. The latest Delphi VCL framework is bugged on Windows 7 home edition.
The company behind Delphi never tested their changes on Windows 7 home edition.
This seems the most likely culprit. It may have something to do with repositioning the window and entering into some kind of weird loop.

3. It could also be some weird kind of bug in windows 7 home edition that get triggered in combination with opengl.

4. However I have something more to report:
Quake 3 Arena demo does not run on the laptop. This game uses opengl, so this is also somewhat suspicious.
It seems to fail at callind CDS bad mode.
It seems Quake 3 is having some kind of create window problem. It cannot find a good resolution.

So something weird is going on with ATI/AMD driver, for now I do not believe it is related to driver version being incremented. This may be something else.

Bye for now,
Skybuck.

skybuck2000

unread,
May 23, 2021, 4:27:44 AMMay 23
to
Investigation part 2:

I did the following in a last attempt to solve any issues:

1. Download and Install and Run "Device Driver Uninstaller".

It removed the driver, it also removed an audio driver though, I will have to re-install this one. Fortunately I have that audio driver too.
For noobies this can be a pain in the ass but ok, worth the trouble to get to the bottom of this. I know how to do it by now so it's breeze normally
speaking.

Well indeed it's a pain in the ass, now it says can't support 7.1 surround sound. I believe there is some trick to getting this working
and something has to be displayed in the device manager. Fucking annoying, that trick not work... shit hard to remember.

Kinda weird how audio driver gets de-installed as well. Perhaps some of it's processing is done through the graphics chip ? or the hdmi part
passing along audio is also part of it somehow, weird and confused about this.

The HD audio driver that was removed is related to HDMI and graphics that is why it is removed. There is another audio chip realtek, but this has no
relation to this. So reinstalling realtek audio driver should not be necessary.

However the 15.1 catalist driver does not work with HDMI.

To support HDMI the 16.1 or whatever version crimsonlive beta version must be installed and this one works pretty ok.

Full details:

Toshiba Laptop L670 HDMI not working:

To solve this issue the following driver must be installed:

Graphics Driver for AMDI Mobility Radone 5000 series:

non-whql-win8.1-win7-radeon-software-crimson-relive-16.2.1-sep20.exe



(The other driver does not work):

whql-win8.1-win7-catalyst-15.7.1-oct30.exe

Do not bother installing it, I already tested it, HDMI does not work on this older driver !


2. Identified the manufacturer and device id and looked it up on device hunt website.

3. Tried latest software from AMD but does not support old graphics chip

4. Did not bother downloading any new drivers because I already have the same install versions on the harddisk.

5. Instead of going with beta or anything crazy decided to go ultra safe and only install WHHQ certified driver.

6. Everything went smooth/rebooting etc.

6.1 I did notice the screen becoming slightly less bright, this might be some graphics settings that I might need to look into later.

7. Decide to run Quake 3 it still did not start. Quake 3 is on USB drive. It is a resolution problem.

Decided to rename q3config so that quake3 re-create a new config.

The game now starts at 800x600 and plays well.

Decided to modify q3config.cfg in demoq3 folder to change to custom resolution:

seta r_mode "-1"
seta r_customheight "900"
seta r_customwidth "1600"
seta cg_drawfps "1"
seta cg_fov "106.26"

Plus some other slightly higher quality settings from the internet.

This does make the game look a bit better.

However the video fails to display/render, the audio is hearable though.

So the resolution problem of Quake 3 was an unrelated issue and a Quake 3 issue, it simply has limited
build-in resolution options and can't detect the resolution of the screen/monitor properly.
This is solveable by custom setting it as done above.

8. Then decided to run my little corona game which uses opengl. It started immediately.

For this I have some explanations:

Possibilities:

8.1 Because I did not shutdown some AMD services, one of the AMD services actively loads the OpenGL driver during boot-up/start-up of windows.
If this service is disabled then that might explain why the OpenGL subsystem has to load the driver, if this hypothesis is correct though.
I doubt that.

8.2 Ofcourse since Quake3 ran and Quake3 already triggers the load of the opengl sybsystem, so must do a reboot first. Going to do that anyway
for audio driver.

8.3 Perhaps the removing and installing of driver fixed it, not sure yet.

9. No slowdown is noticed for leaving the MOM.exe and CCC.exe running, these are part of the AMD driver suite. I probably disabled these to reduce
memory and processor consumption just to optimize the system and also provide any spieing from AMD :), call me paranoid ! =D. Maybe also
to prevent any stupid updates or whatever, don't like that if I am in middle of "important" game session or whatever =D
Perhaps this is part of the reason the opengl subsystem wasn't loaded at startup...

10. For now I have decided to simply let these services from AMD run to avoid any opengl startup issues.

11. One thing was learned from all of this "OpenGL" somewhat unreliable for software usage/rendering and a fallback mechanism should be available
at the very least to circumvent these kind of software issues on systems.

12. It does annoy me to see CCC.exe in the process list. It pisses me off that AMD can't name their executables properly. Now it truely looks
like malware/spyware, but it's not ! Very stupid of AMD ! ;) Only advantage to this is when task manager is very small displayed.

Other things now running are: atieclxx.exe atiesrxx.exe

13. It appears this official driver does not provide 7.1 surround sound playback through HDMI, actually it offers no HDMI playback at all.

A major driver fuck up as far as I am concerned by AMD.

This leaves me with no other choice then remove this AMD driver and try the beta driver to see if it does offer a HDMI fix.

This is quite annoying to have to do this all over again.

But first I test my game to see if this WHQL driver solves the problem or not... without disabling any services.

I do notice TASK manager has problems starting up on startup of computer... it will freeze for a while.

This could indicate a deeper problem in windows 7 home version... after some seconds but starting up a second task manager
this problem seems to go away but only if not too much software starts up otherwise it could be an annoying problem ! ;)

SURPRISE SURPRISE, THE PROBLEM REMAINS... THIS IS SIMPLY A DRIVER PROBLEM OR WINDOWS 7 HOME EDITION PROBLEM OR A BIG FAT BUG IN VCL OF DELPHI...

VERY WEIRD AND VERY STRANGE, ONE THING I COULD TRY IS COMPILE WITH AN OLDER VERSION OF DELPHI TO SEE IF PROBLEM GOES AWAY...

COULD ALSO BE A PROGRAMMING BUG BY ME, BUT WHY WOULD IT THEN HAPPEN ON ONE SYSTEM AND NOT THE OTHER ONE.... VERY STRANGE.

Well it does happen on PC too apperently, but nvidia driver starts up faster somehow or the problem is less severe...

VERY STRANGE... could also be a fluck of luck sometimes but now it is pretty reproduceable on PC too but less noticeable

perhaps because GT 1030 is faster... hmmm strange... The opposite could also be the case.

Because the laptop CPU is faster the spin loop/infinite loop is much more severe and causes a harder lock-up of the startup process.

It's not the first time Pascal software has been hit by some weird SPEED bug... Turbo Pascal is also know to be affected by a speed bug during
initialization of Pascal software because of a wrap around counter.

Apperently now Delphi has also an issue like this and it is going unnoticed for now. UNTIL CPUs become much faster and then it will show
it's old ugly head again !


14. To determine if this issue is present in Delphi, a very simple VCL application will be created by me with nothing else then
a button to debug/profile that to see if it shows the same behaviour or not.

I did no problems noticed.

15. After lots of shitting around/debugging and trying things I come to the following conclusion:

the delphi/vcl property Canvas.Handle calls a lot of code, is complex and might be one of the causes of the slow down.

It was called multiple times in the WM_CREATE.

I experimentally replaced this with code like this in pseudo form:

if vcl in design state then
store canvas handle := canvas.handle;
else
store canvas handle := GetDC( Handle );
end

... then in the rest of the code use the "local" "store canvas handle"

Now the game seems to start fast !

Why this prevent issues I am not sure, maybe just slow code.

However in the debugger I still see a lot of looping/function calls.

So it doesn't solve it completely, the issue might still be present but less noticeable...

So I am not sure this fully solves it but so good so far... for now.

Bye,
Skybuck.



skybuck2000

unread,
May 23, 2021, 5:13:55 AMMay 23
to
I found and consulted my older postings about this, fortunately those still on google newsgroups.

GetDC doesn't work well in design state it's value is always different between api calls and such.

So for now I have decided to implement it this way:

function TOpenGLControl.GetDeviceContext : HDC;
begin
if not (csDesigning in ComponentState) then
begin
result := GetDC(Handle);
end else
begin
result := Canvas.Handle;
end;
end;

And then in whatever code a device context is necessary it calls this function:

GetDeviceContext.

The only drawback so far is that it crashes the IDE when the topengl control is put on a form, why exactly I don't know but it might have something to do with the IDE not being able to find the source code or whatever.

I like adding those manually to projects. It could also be some new bug in the IDE, after the project is fixed by adding the graphics units and saved and re-opened all should work fine.

Now I go test it further by re-compilg some of my applications and corona game to solve this weird slow startup hopefully once and for all because it's quite annoying.

It could also be that VCL has a bug which gets more severe as the CPU speed increases !

So Delphi creator be warned and debug your VCL better ! In some rare cases it can behave strangely, still haven't found the exact cause of it... so far so good though...

It may also have to do something with critical sections being locked and unlocked.

Or maybe it trips up the dbg spider...

I am still not 100% convinced this solves it once and for all but it does make the situation better.

It could also be a weird bug in windows 7 home edition or in AMD/ATI driver which is beta, but also the official driver also showed some behaviour.

And same behaviour also noticed on PC/nvidia... windows 7 ultimate edition...

So the mystery remains somewhat but is now less severe.

Bye for now,
Skybuck.
Reply all
Reply to author
Forward
0 new messages