OpenGL works slow without graphics drivers, and also in Virtual Machines (VMWare) ?

Hello,

I suspect OpenGL works very slow without graphics drivers on operating
systems and also works very slow in virtual machines like VMWare.

I am not sure what the cause of the slowdown is... it could be "opengl
array" related issues, like glDrawArrays it could also be glClear it could
also be glCopyPixels.

It's somewhat surprising that OpenGL is so slow and GDI so fast.

OpenGL seems 1000x slower than GDI in these kinds of situations.

This makes it seem that OpenGL is unsuited as a general graphics purposes
layer.

It's a risk for software/application developers.

Especially since Virtualization is populair.

Even a modern Windows Professional x64 Virtualized Operating System shows
the tremendous slow down.

Either there is a really strange bug in my own application or something
really weird is going on with OpenGL.

Anybody have samiliar experiences with OpenGL without graphics drivers
installed or OpenGL in virtual environments ?!?

Bye,
Skybuck.

Virtualbox ( http:/www.virtualbox.org ) supports accelerated opengl on
linux, well does with my virtual ubuntu installation anyway...

"Skybuck Flying" wrote in message
b.home.nl...

Hello,

I suspect OpenGL works very slow without graphics drivers on operating
systems and also works very slow in virtual machines like VMWare.

I am not sure what the cause of the slowdown is... it could be "opengl
array" related issues, like glDrawArrays it could also be glClear it could
also be glCopyPixels.

It's somewhat surprising that OpenGL is so slow and GDI so fast.

OpenGL seems 1000x slower than GDI in these kinds of situations.

This makes it seem that OpenGL is unsuited as a general graphics purposes
layer.

It's a risk for software/application developers.

Especially since Virtualization is populair.

Even a modern Windows Professional x64 Virtualized Operating System shows
the tremendous slow down.

Either there is a really strange bug in my own application or something
really weird is going on with OpenGL.

Anybody have samiliar experiences with OpenGL without graphics drivers
installed or OpenGL in virtual environments ?!?

Bye,
Skybuck.

On Jul 13, 2:07*am, "Skybuck Flying"
wrote:
Hello,

I suspect OpenGL works very slow without graphics drivers on operating
systems and also works very slow in virtual machines like VMWare.


Oh, RLY?

I am not sure what the cause of the slowdown is... it could be "opengl
array" related issues, like glDrawArrays it could also be glClear it could
also be glCopyPixels.


LOL! That's a list of all the things that *aren't* causing the
problem....

It's somewhat surprising that OpenGL is so slow and GDI so fast.

Does GDI do shading/texturing/lighting/depth buffering....?

The OpenGL application is simply clearing the screen and drawing some boxes
and then flipping it to the screen (copy pixels).

Yet it's still very slow without a graphics driver.

Even windows 95 on a 80486 is 1000x faster than the modern computers.

So something odd is going on.

Bye,
Skybuck.

"Skybuck Flying" wrote in
b.home.nl:

Hello,

I suspect OpenGL works very slow without graphics drivers on operating
systems and also works very slow in virtual machines like VMWare.

I am not sure what the cause of the slowdown is... it could be "opengl
array" related issues, like glDrawArrays it could also be glClear it
could also be glCopyPixels.

It's somewhat surprising that OpenGL is so slow and GDI so fast.

OpenGL seems 1000x slower than GDI in these kinds of situations.

This makes it seem that OpenGL is unsuited as a general graphics
purposes layer.

It's a risk for software/application developers.

Especially since Virtualization is populair.

Even a modern Windows Professional x64 Virtualized Operating System
shows the tremendous slow down.

Either there is a really strange bug in my own application or
something really weird is going on with OpenGL.

Anybody have samiliar experiences with OpenGL without graphics drivers
installed or OpenGL in virtual environments ?!?

Bye,
Skybuck.




Are you just trolling us?

Go load the proper graphics driver for your system, fer cryin' out
loud....

Perhaps it's possible to compile/build the application/my tool in such a way
that profiling information from a tool like qatime is added.

Then this executable could be transferred to windows 95 (However I would
expect qatime code to fail because of old platform).

Then this executable could be transferred to windows x64 pro virtualized os
and hopefully get some performance metrics.

This would then save me quite some time... no need to go add profiling code
manually, no need to start guessing where the slow down might occur.

Hopefully qatime modified executable can then collect profiling data, and
hopefully this can then be transferred back to my debugging/development
system for a looksy.

Failing that it would be interesting if windows 7 had a "default graphics
driver" mode to test my app under default windows 7 conditions.

Perhaps windows 7 still has safe mode which might work like that

Bye,
Skybuck.

Getting to the bottom of this is probably going to be easier than I thought.

The virtualized windows x64 pro has delphi 2007 on it which also had qatime
installed right before it died sorta... now it's revived so it can be used.

Right now I am getting to the bottom of it. So far it already appears to be
a problem with opengl.

Either it's painting too slow, or there is another problem.

I am now going to split up the paint method to see which part takes the long
time.

Then I will report back

Bye,
Skybuck.

I have profiled the application and this is the opengl call which causes the
major slowdown:

glFlush;

I suspect this function pushes all the previous commands to the opengl
driver and expects the opengl driver to complete them.

All other application routines seem to execute just fine.

So possible conclusion:

The slow down happens somewhere inside of the opengl driver.

Therefore further profiling the application itself would be useless.

Therefore I need some kind of opengl profiler which can profile opengl
itself/the driver.

Bye,
Skybuck.

On Jul 17, 9:07*am, "Skybuck Flying"
wrote:
I have profiled the application and this is the opengl call which causes the
major slowdown:

glFlush;


LOL!

I suspect this function pushes all the previous commands to the opengl
driver and expects the opengl driver to complete them.


But you can't possibly read any documentaion
to confirm/deny your "suspicion", right ...

.... because reading documentation just isn't the way
starbucky rolls.

Actually I remember there was only one rectangle being drawn (before that a
clear) so it's definetly not a case of to much stuff to render, which leaves
one last possibility, some kind of strange bug in the opengl software driver
?! (Or the clear is causing the slow down)

Bye,
Skybuck.