OpenGL works slow without graphics drivers, and also in Virtual Machines (VMWare) ?
Skybuck Flying
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.
Nobody
> I suspect OpenGL works very slow without graphics drivers on operating
> systems and also works very slow in virtual machines like VMWare.
Are you using features for which the drivers for the virtualised hardware
fall back to software?
Looking at:
http://www.vmware.com/support/ws7/doc/releasenotes_ws7.html
it says that it supports OpenGL 1.4 and shader model 2.0 for Vista and
Windows 7 guests and OpenGL 2.1 and shader model 3.0 for XP guests.
> It's somewhat surprising that OpenGL is so slow and GDI so fast.
Not really. GDI is *much* simpler than OpenGL; it was designed to have
reasonable performance on an 8086 without hardware graphics acceleration.
OpenGL was never intended for software-only implementation.
> This makes it seem that OpenGL is unsuited as a general graphics purposes
> layer.
OpenGL is bound to be slow on systems which lack hardware acceleration.
But that's true of anything which provides similar functionality
(sub-pixel precision, linear transformations, anti-aliasing, etc).
Charles E Hardwidge
"Nobody" <nob...@nowhere.com> wrote in message
news:pan.2011.07.13....@nowhere.com...
> http://www.vmware.com/support/ws7/doc/releasenotes_ws7.html
>
> it says that it supports OpenGL 1.4 and shader model 2.0 for Vista and
> Windows 7 guests and OpenGL 2.1 and shader model 3.0 for XP guests.
That fruitloop never reads the documentation.
VMWare and OpenGL worked fine for me when I gave it a test drive just after
it was released by playing Jedi Outcast ages ago. Boom-banga-bang.
--
Charles E Hardwidge
David
linux, well does with my virtual ubuntu installation anyway...
"Skybuck Flying" wrote in message
news:78815$4e1ce1cf$5419acc3$17...@cache6.tilbu1.nb.home.nl...
fungus
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....?
jbwest
Don't egg Skybuck on, just ignore him. He doesn't know a thing.
jbw
Skybuck Flying
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.
Zootal
news:78815$4e1ce1cf$5419acc3$17...@cache6.tilbu1.nb.home.nl:
Are you just trolling us?
Go load the proper graphics driver for your system, fer cryin' out
loud....
Skybuck Flying
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.
Skybuck Flying
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.
Skybuck Flying
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.
fungus
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.
Skybuck Flying
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.
Skybuck Flying
Bye,
Skybuck.
Skybuck Flying
I took a lazy approach and simply disabled some open api calls which were
probably queueing opengl commands.
Then I started to get a hunch for what the problem was:
It turns out the "double" buffering is causing a major slowdown:
When mOptionDoubleBufferEnabled is set to true, things become extremely
slow.
When mOptionDoubleBufferEnabled is set to false, everything runs faster, but
the drawing starts to flicker :(
I don't think GDI would flicker that much... this means opengl software
driver just sucks compared to gdi.
// if double buffering is enabled then draw to backbuffer
if mOptionDoubleBufferEnabled then
begin
mOpenGLAPI.glDrawBuffer( GL_BACK );
end else
// else draw to front buffer
begin
mOpenGLAPI.glDrawBuffer( GL_FRONT );
end;
... opengl draw codes...
// if double buffering is enabled then we still need to copy it to the
front buffer
if mOptionDoubleBufferEnabled then
begin
mOpenGLAPI.glReadBuffer( GL_BACK );
mOpenGLAPI.glDrawBuffer( GL_FRONT );
mOpenGLAPI.glCopyPixels( 0, 0, ClientWidth, ClientHeight, GL_COLOR);
end;
mOpenGLAPI.glFlush;
Bye,
Skybuck.
Skybuck Flying
// glCopyPixels not used this api any more as it seems the cause of the slow
down.
// glFlush perhaps also leave this out.
And instead use:
SwapBuffers( Canvas.Handle ); // windows api call.
From what I can remember I didn't like this solution at first because this
limits the rendering speed of opengl to 60 hz or so... or it adds some
milliseconds of waiting time.
As I wanted to use the same code for gpgpu or so.... I didn't want this 60
hz limitation/retrace limitation.
But it seems this has to be used for slower systems.
Swapping the buffers instead of copieing the pixels makes sense... I can
imagine the swap buffer call to simply swap some pointers here and there.
The performance is much better, and double buffering can be used so no more
blinking.
Even when double buffering is off it seems to work, not yet sure why... and
no flicker so far.
It's note worthy to note that previous method was faster for single
buffering but produced unwanted flicker.
I am not sure if the ReadBuffer call and the DrawBuffer call are still
needed. From what I remember these specify the source and dest buffer for
the glCopyPixels call, so these calls can probably be left out.
I can vaguely remember SwapBuffers to work with two buffers always... it
seems to make sense... one offline and one online buffer... so any other
buffer calls probably not needed when using this api.
Well now I know how to fix my application so it runs on "default windows"
with acceptable speed and no flicker...
Bye,
Skybuck.
Skybuck Flying
to for safe heaven...
Because ya never know... opengl could have more unpleasent surprises ! ;) =D
Bye,
Skybuck =D
Nobody
> 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.
That's half-right; glFlush() pushes all outstanding commands to the
driver. It doesn't wait for completion, but it won't return until all
commands have actually been "sent" (whatever that means for a particular
implementation), so if the outstanding commands exceed the space available
in intermediate buffers, it may have to wait for some of the commands to
complete (in order to free up buffer space) before it can finish sending
the commands.
glFinish() behaves like glFlush() but also waits for all commands to complete.
> Therefore I need some kind of opengl profiler which can profile opengl
> itself/the driver.
One option is to add glFinish() calls to your code, so that you can
determine the total time required for a given sequence of instructions.
Using divide-and-conquer, you may be able to isolate a specific operation
which is particularly slow.
Nobody
> mOpenGLAPI.glReadBuffer( GL_BACK );
> mOpenGLAPI.glDrawBuffer( GL_FRONT );
> mOpenGLAPI.glCopyPixels( 0, 0, ClientWidth, ClientHeight, GL_COLOR);
Use SwapBuffers, glXSwapBuffers, etc instead.
Charles E Hardwidge
> Using divide-and-conquer, you may be able to isolate a specific operation
> which is particularly slow.
I think we've identified that one...
--
Charles E Hardwidge
Quadibloc
OpenGL and Direct X both provide graphics-intensive programs with a
standardized interface for doing things applicable, for example, to 3D
animation.
This replaces having to write those programs only to work with the
graphics acceleration on one particular video card - or with modules
for all the different video cards.
So, if you don't have the drivers, if you are inside a virtual machine
which has just a plain Super VGA card without acceleration, your
OpenGL driver has to do all the computational work itself, without
making use of the graphics acceleration features of your video card.
As you've observed, this causes a major slowdown.
Profiling is not the answer. The answer is to either get the drivers,
or have one's virtualization software pass through the type of video
card you actually have - select that video card in one's virtual
machine, and ensure that the virtualization software handles it by a
pass-through.
John Savard
fungus
wrote:
> What makes you believe that the documentation will help me ?
>
Well ... It usually helps *me* when I read it (which
I often do)
Leclerc
>>
>
> Well ... It usually helps *me* when I read it (which
> I often do)
>
I don't know whether it is a rule or exception, but reading docs helps
me as well ...
David
What makes you believe that the documentation will help me ?
Bye,
Skybuck.
You see this is why I don't block this guy, some of his comments are
hilarious.
Almost worth quoting that one.
Thanks Skybuck :D
fungus
>
> You see this is why I don't block this guy, some of his comments are
> hilarious.
>
Yep.
Quadibloc
> "Skybuck Flying" wrote in message
> news:7190d$4e2294fd$5419acc3$19...@cache6.tilbu1.nb.home.nl...
>
> What makes you believe that the documentation will help me ?
> You see this is why I don't block this guy, some of his comments are
> hilarious.
His comment would be _more_ hilarious if the documentation that came
with video cards these days said anything more than "avoid static
electricity when you plug it in".
It is true that, as I noted in my post, some basic understanding of
what OpenGL is and does would clear up the problem. And, if one knows
where to look online, there is a lot of information about OpenGL,
including documentation by the open-source project behind it.
But if one is looking *there*, there is quite a wealth of material
available, and without the basic understanding needed to know *where
to begin looking*, it's entirely possible he would fail to be helped
for another reason.
John Savard
Skybuck Flying
It does come as surprise, since Windows 95 with 80486 with 33 Megahertz
works faster than the virtual machine so something must have been wrong...
I should do some benchmarks to see how many instructions windows 95 can
execute on a real machine versus a virtual machine on a modern computer.
And then some more tests of windows x64 pro in virtual machine.
Just the fact that windows x64 pro runs in a virtual machine is a good
indication that the virtual machine is actually quite fast and at least has
sufficient ram available.
So either it's the ram which makse x64 run fast, or it's the processor not
sure which.
If it would be the ram then even a 80486 might be able to run such a big
operating system.
But I don't think so... I would think the 33 mhz is simply not enough and
would take ages.
Thus conclusion: somethings wrong if an opengl app works decently on a 486
with no real hardware accelleration, just simple super vga, and then
suddenly it runs slow in a virtual machine ;)
My best bet is:
The opengl software does some strange pixel format conversions, or it simply
has a really really slow pixel copy routine for glCopyPixels.
Which in itself is an interesting question:
Why would glCopyPixels still be fast on a real 80486 machine (with tseng
4000 graphics card) ? At least I thought it was...
Perhaps it was slow too... but I don't think so... I have seen either opengl
apps of my run on windows 95 and they had no problems with graphics... but
perhaps it used the swapbuffers at the time instead of the glCopyPixels...
so perhaps I should try again, just to make sure if glCopyPixels is fast or
slow on real svga hardware ! ;) :)
Bye,
Skybuck.
Nobody
> It does come as surprise, since Windows 95 with 80486 with 33 Megahertz
> works faster than the virtual machine so something must have been wrong...
>
> I should do some benchmarks to see how many instructions windows 95 can
> execute on a real machine versus a virtual machine on a modern computer.
Virtualisation isn't the same thing as emulation. A VM has the CPU execute
(most) instructions directly; it doesn't emulate the CPU.
However: it has to know how to virtualise each piece of hardware.
Virtualising the CPU is a given; if it can't do that, it can't run
anything. Other hardware will effectively be emulated unless you install
drivers for it.
> My best bet is:
>
> The opengl software does some strange pixel format conversions, or it simply
> has a really really slow pixel copy routine for glCopyPixels.
>
> Which in itself is an interesting question:
>
> Why would glCopyPixels still be fast on a real 80486 machine (with tseng
> 4000 graphics card) ? At least I thought it was...
If OpenGL is accessing the hardware directly, glCopyPixels is just a
"blit" operation, which can typically be performed by the hardware, even
on a mid-90s VGA card. However, it's possible that, without drivers, the
VM is actually copying the data from video memory to system memory then
back to video memory.
> Perhaps it was slow too... but I don't think so... I have seen either opengl
> apps of my run on windows 95 and they had no problems with graphics... but
> perhaps it used the swapbuffers at the time instead of the glCopyPixels...
> so perhaps I should try again, just to make sure if glCopyPixels is fast or
> slow on real svga hardware ! ;) :)
glCopyPixels might be slower than SwapBuffers (etc), as the operation is
subject to the state set by glPixelTransfer, glPixelMap, and glPixelZoom.
SwapBuffers doesn't do any conversions.
Also, both glCopyPixels and SwapBuffers have to wait for all outstanding
commands to complete, so any timings for those functions may include the
time taken to execute a significant number of previous rendering commands.
If you want accurate timings, you need to add glFinish() calls to ensure
that you aren't including buffered commands in the results.
GMAN
>"Skybuck Flying" wrote in message
>news:7190d$4e2294fd$5419acc3$19...@cache6.tilbu1.nb.home.nl...
>
>What makes you believe that the documentation will help me ?
>
>Bye,
> Skybuck.
>
>
Dude, getting laid by a woman WOULDN'T help you!
Arivald
> What makes you believe that the documentation will help me ?
Nothing will help You.
But Your lobotomy will help us all.
Will You do it?
--
Arivald
k...@kymhorsell.com
...
> But Your lobotomy will help us all.
> Will You do it?
Contra-indicated.
May have the effect of removing all judgment but boosting confidence.
--
[Rain as the origin of SLR:]
The slow rise of sea level is caused by rain. Water transfer the soil to see.
The acceleration during the last 50 years is caused by using gas and oil
instead of coal. Gas and oil are changed into water during combustion.
So the slow or the accelerated rise of sea level is not a problem.
-- Szczepan Bialek <sz.b...@wp.pl>, 28 May 2011 09:50 +0200
Miles Bader
> ... because reading documentation just isn't the way
> starbucky rolls.
... and I suspect it's a pretty good bet that he rolls.
-miles
--
"Nah, there's no bigger atheist than me. Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian." [Adam Carolla]