NT OpenGL drivers in Windows 95?
Dennis Forbes
I know I am probably COMPLETELY and ABSOLUTELY wrong in this conclusion,
but my silly eagerness to try what is probably impossible led me to an
interesting result.
I've been playing with OpenGL for just a short while, and one of the
letdowns (partly, although I know it is bound to change as a new breed of
high quality OpenGL affordable accelerators hit the scene, and it is our
job as developers to predict those trends in the future so we have products
out when the technology is viable, anyways...) of it has been relatively
low speed. I've been generally playing around with the various libraries,
and OpenGL.
Anyways, on with my story. I'm running Windows 95 and my development
environment is Microsoft Visual C++ 5.0. I've also installed Cosmo GL.
Today while at work I happened upon the Diamond Multimedia website
(www.diamondmm.com) and went to see if there were any new drivers for my
video card (a Diamond Stealth 3D 3000...not too fast at 3D, but what the
heck). I scrolled down a bit and noticed that in the NT 4.0 driver
section, it states MCD support for OpenGL....hrmmm, I think. I have no
idea how video drivers are implemented in either environment (I've never
had a need to know), but I realize this is probably technically impossible.
I downloaded the NT 4.0 driver, supposedly with the OpenGL support, and
proceeded to try to install in in Windows 95. Windows 95 (with Service
Pack 1) recognized the driver as a video driver, and proceeded as normal.
It prompted me to restart Windows, which I did with no problem. It now
assures me that it is running, somehow, the NT 4.0 driver. Now for the
curious part...
Like I said, I haven't been doing this OpenGL gig for long, but I have been
amazed with the idea of Cosmo GL. Now I'm very curious with the idea that
maybe, perhaps the OpenGL acceleration routines were actually linked into
the OS, which would definitely improve speed as the fill rate seemed to be
the biggest holdback with software rendering, yet the video card has no
fill rate problems. I loaded up and slightly modified the sphere.c example
delivered with Cosmo OpenGL (in examples), modifying it to make a window
780 pixels wide, 580 pixels high, at a 24-bit depth, and to draw the sphere
with 100 iterations and time the total process time. I then linked in the
CosmoGL libraries (before the gdi.lib, a tip given by a helpful chap in
this newsgroup). It worked and rendered fine (although choppily), and the
total rendering took a grand 15 seconds (give or take 1/4 second).
I then removed the cosmoGL.lib and put in the Microsoft OpenGL libraries,
specifying PFD_GENERIC_ACCELERATED (not quite sure if the flag is right...?
Cosmo OpenGL would not allow me to specify this flag when it was active).
I then reran the test. Visually the result was the same, but it was
obviously much faster. The test completed in just under 10 seconds (about
9.8).
Whats happening here? How did the Microsoft library end up being faster?
Is this a single bad example where Cosmo OpenGL isn't at an advantage, did
the PFD_GENERIC_ACCELERATED do something drastic to speed things up, or
did, and again I realize this may be a assertion foolish beyond belief, the
NT 4.0 OpenGL drivers actually work and allow the Stealth 3D 3000, although
its quite slow, to speed things up?
I am very, very curious to say the least, and would be very interested in
anything anyone may have to say about this. Emailed replies to
dfo...@execulink.com, or in the newsgroup would be great.
Thanks!
---
Dennis W. Forbes
dfo...@execulink.com [Woohoo! Here comes another stream of lame
triangle scheme emails...]
Michael I. Gold
"Dennis Forbes" <dfo...@execulink.com> writes:
| Whats happening here? How did the Microsoft library end up being faster?
| Is this a single bad example where Cosmo OpenGL isn't at an advantage, did
| the PFD_GENERIC_ACCELERATED do something drastic to speed things up, or
| did, and again I realize this may be a assertion foolish beyond belief, the
| NT 4.0 OpenGL drivers actually work and allow the Stealth 3D 3000, although
| its quite slow, to speed things up?
Had Microsoft's opengl32.dll actually recognized the MCD, cosmogl.dll
would have automatically routed the calls through to opengl32.dll, and
the timings would have been identical. We did this so that cosmogl.dll
would not be a "decelerator" on machines with hardware support.
Therefore I conclude that the MCD was not active, as you predicted.
Until Microsoft releases MCD support for Win95, opengl32.dll will
ignore the presence an an MCD (even if the vendor ships a Win95 MCD).
As for the results of your benchmark; the release notes for Cosmo
OpenGL explain that we have not optimized for 24-bit framebuffers in
the current beta. If you run your test in 8, 15, 16, or 32 bit, it
will almost certainly run faster. The other thing to consider is that
the sphere example is intended more as a triangle throughput benchmark
than a fill rate benchmark. To measure raw fill rates, use rb and
measure 10k pixel triangles, rendering to the backbuffer. Source for
rb is in "\Program Files\Cosmo\OpenGL\rb"
--
Michael I. Gold Silicon Graphics Inc. http://reality.sgi.com/gold
And my mama cried, "Nanook a no no! Don't be a naughty eskimo! Save your
money, don't go to the show!" Well I turned around and I said, "Ho! Ho!"
Alberto C Moreira
In article <5lbpij$h...@fido.asd.sgi.com>, go...@asd.sgi.com.spam-free says...
> "Dennis Forbes" <dfo...@execulink.com> writes:
>
> | Whats happening here? How did the Microsoft library end up being
faster?
> | Is this a single bad example where Cosmo OpenGL isn't at an advantage,
did
> | the PFD_GENERIC_ACCELERATED do something drastic to speed things up, or
> | did, and again I realize this may be a assertion foolish beyond belief,
the
> | NT 4.0 OpenGL drivers actually work and allow the Stealth 3D 3000,
although
> | its quite slow, to speed things up?
>
> Had Microsoft's opengl32.dll actually recognized the MCD, cosmogl.dll
> would have automatically routed the calls through to opengl32.dll, and
> the timings would have been identical. We did this so that cosmogl.dll
> would not be a "decelerator" on machines with hardware support.
> Therefore I conclude that the MCD was not active, as you predicted.
> Until Microsoft releases MCD support for Win95, opengl32.dll will
> ignore the presence an an MCD (even if the vendor ships a Win95 MCD).
Let me try to make this clear, I'm not sure I fully understand. As far as I
know, the MCD model isn't compatible with Win95 graphics drivers, but I may
be wrong.
If you were using NT, it comes with opengl32.dll installed. The NT version
of opengl32.dll recognizes the existence of the MCD and passes control to
it, therefore enabling hardware providers to accelerate OpenGL calls.
If the driver has an MCD, speed depends on the quality of the MCD and of the
extent that the graphics hardware accelerated 3D rendering. If the driver
does not have an MCD (or an ICD), a lot of rendering is done to memory, and
speed will increase with the quality of the graphics subsystem's bitblt -
but this will probably be slower than rendering to an MCD.
Now, enter Cosmo. If you link your app with Cosmo, it seems to have smarts
to recognize whether opengl32.dll is there, and if opengl32.dll tells Cosmo
there's an MCD underneath, Cosmo gets out of the way and punts everything to
opengl32.dll. If opengl32.dll does not see an MCD - and there is no MCD in
Win95 - Cosmo will do its job and render via software.
The bottom line is, opengl32.dll holds the keys to the kingdom.
On Win95, however, things are slightly different. I wasn't aware that the
Win95 driver standard accomodated an MCD, but I may be wrong. By the looks
of it, Win95 does accomodate an ICD, and I hope Microsoft's Win95 rendition
of opengl32.dll passes control to the ICD when it sees one. Remember, Win95
drivers are 16-bit and adhere to the old Win3.1 DDI; they work in a
segmented environment; and they require that the GDI controls the flow of
events. Unless the GDI is changed to accomodate the MCD API, there is no
possibility of having a Win95 MCD.
One way to alleviate this issue, and I tought SGI had it implemented or at
least was working on it, is to have Cosmo render through Direct Draw. Win95
drivers usually have a good deal of DD acceleration, and although this won't
undo the performance advantage of 3D hardware acceleration, that may be
faster than rendering to the GDI or just blitting memory surfaces out.
Alberto.
Dennis Forbes
Michael I. Gold <go...@asd.sgi.com.spam-free> wrote in article
<5lbpij$h...@fido.asd.sgi.com>...
> Had Microsoft's opengl32.dll actually recognized the MCD, cosmogl.dll
> would have automatically routed the calls through to opengl32.dll, and
> the timings would have been identical. We did this so that cosmogl.dll
> would not be a "decelerator" on machines with hardware support.
> Therefore I conclude that the MCD was not active, as you predicted.
> Until Microsoft releases MCD support for Win95, opengl32.dll will
> ignore the presence an an MCD (even if the vendor ships a Win95 MCD).
Aha! Okay, that makes sense. To be honest, by far my main interest in
this was the fact that Windows 95 seems to believe it is successfully
running the NT 4.0 drivers, and I was just curious if the architecture of
the OpenGL was similar enough that MCD drivers made for NT would work for
95. But obviously if MCD isn't even supported on 95 yet, that's pretty
much out of the question. Out of curiousity, why does Cosmo OpenGL fail if
you flag PFD_GENERIC_ACCELERATED? I'm somewhat unsure as to what exactly
this flag does, to be totally honest.
> As for the results of your benchmark; the release notes for Cosmo
> OpenGL explain that we have not optimized for 24-bit framebuffers in
> the current beta. If you run your test in 8, 15, 16, or 32 bit, it
> will almost certainly run faster. The other thing to consider is that
> the sphere example is intended more as a triangle throughput benchmark
> than a fill rate benchmark. To measure raw fill rates, use rb and
> measure 10k pixel triangles, rendering to the backbuffer. Source for
> rb is in "\Program Files\Cosmo\OpenGL\rb"
Ah. Well, yer right there. Although I didn't do the sphere (because I
kept rebuilding the project with different example sources. My results
would probably be more valid if I did these tests before installing, but I
was just amazed that Windows 95 even let me install the driver...or at
least thinks it did) in 8-bit, I did do the cube and there the Cosmo OpenGL
(I know it was renamed, but I sure like CosmoGL a lot better... ;^)) did
beat the MS implementation (by about 20%), although I have to cry that both
were very, very slow (at about 780 pixels x 580 pixels). It seemed that
the fill rate was the mail problem. Although I know absolutely nothing
about this worth spouting my opinions in public, in that case, as the
shading was absolutely the same on the entire polygon, couldn't you just
send the polygon to the video card to be drawn? I'm very, very certain the
video card could draw and fill the polygon in a thousandth or so the time
it is taking the software to draw and fill the polygon. This wouldn't work
for other shading models, but it would work for it. Unless the cube demo
is intentionally doing software fills of polygons.
Cheers!
BTW: OpenGL is a remarkably elegant and beautiful product that actually
makes sense. I do admit wishing there was a bit more speed there, but I
know that'll come.
Michael I. Gold
amor...@nine.com (Alberto C Moreira) writes:
| Let me try to make this clear, I'm not sure I fully understand. As far as I
| know, the MCD model isn't compatible with Win95 graphics drivers, but I may
| be wrong.
Its not currently shipped but work to support MCD on Win95 has
apparently been completed for a couple of months. The paranoid part of
me believes that Microsoft is holding up its release for "political
reasons" (e.g. the D3D team is feeling the heat and MS doesn't want to
"help" OpenGL; just as they are holding up the release of DirectDraw
support).
| If you were using NT, it comes with opengl32.dll installed. The NT version
| of opengl32.dll recognizes the existence of the MCD and passes control to
| it, therefore enabling hardware providers to accelerate OpenGL calls.
Yes.
| If the driver has an MCD, speed depends on the quality of the MCD and of the
| extent that the graphics hardware accelerated 3D rendering. If the driver
| does not have an MCD (or an ICD), a lot of rendering is done to memory, and
| speed will increase with the quality of the graphics subsystem's bitblt -
| but this will probably be slower than rendering to an MCD.
Yes.
| Now, enter Cosmo. If you link your app with Cosmo, it seems to have smarts
| to recognize whether opengl32.dll is there, and if opengl32.dll tells Cosmo
| there's an MCD underneath, Cosmo gets out of the way and punts everything to
| opengl32.dll. If opengl32.dll does not see an MCD - and there is no MCD in
| Win95 - Cosmo will do its job and render via software.
Almost. The current beta of Cosmo always punts to opengl32.dll on NT.
The next release will support NT and therefore punt only if/when
hardware acceleration is detected. Note that the "hand-off" to
opengl32.dll occurs for either and ICD or an MCD.
| The bottom line is, opengl32.dll holds the keys to the kingdom.
Well, lets just say it currently holds the keys to hardware
acceleration. ;-)
| On Win95, however, things are slightly different. I wasn't aware that the
| Win95 driver standard accomodated an MCD, but I may be wrong. By the looks
| of it, Win95 does accomodate an ICD, and I hope Microsoft's Win95 rendition
| of opengl32.dll passes control to the ICD when it sees one. Remember, Win95
| drivers are 16-bit and adhere to the old Win3.1 DDI; they work in a
| segmented environment; and they require that the GDI controls the flow of
| events. Unless the GDI is changed to accomodate the MCD API, there is no
| possibility of having a Win95 MCD.
Hmm. There is no 16-bit code in Cosmo OpenGL. I would really be
surprised if there is 16-bit code in opengl32.dll. In any case, I
believe the changes to support MCD in Win95 have already been made, but
not released.
| One way to alleviate this issue, and I tought SGI had it implemented or at
| least was working on it, is to have Cosmo render through Direct Draw. Win95
| drivers usually have a good deal of DD acceleration, and although this won't
| undo the performance advantage of 3D hardware acceleration, that may be
| faster than rendering to the GDI or just blitting memory surfaces out.
We'll certainly support rendering to DirectDraw surfaces in the next
release. However, this is not a complete solution - MCD support for
Win95 is still highly desireable. I know Microsoft prefers the MCD
model, but they are forcing IHV's to write ICD's by not releasing the
DDK.
Michael I. Gold
"Dennis Forbes" <dfo...@execulink.com> writes:
| Aha! Okay, that makes sense. To be honest, by far my main interest in
| this was the fact that Windows 95 seems to believe it is successfully
| running the NT 4.0 drivers, and I was just curious if the architecture of
| the OpenGL was similar enough that MCD drivers made for NT would work for
| 95. But obviously if MCD isn't even supported on 95 yet, that's pretty
| much out of the question. Out of curiousity, why does Cosmo OpenGL fail if
| you flag PFD_GENERIC_ACCELERATED? I'm somewhat unsure as to what exactly
| this flag does, to be totally honest.
If both GENERIC_ACCELERATED and GENERIC_FORMAT are set in dwFlags, you
have an MCD. If neither is set you have an ICD. Since Cosmo OpenGL
supports neither, it fails when you request GENERIC_ACCELERATED.
Perhaps we should just ignore this flag. I recommend examining the
pixel formats which an implementation returns, and selecting one based
on such information, rather than setting this flag in a
ChoosePixelFormat request.
| Ah. Well, yer right there. Although I didn't do the sphere (because I
| kept rebuilding the project with different example sources. My results
| would probably be more valid if I did these tests before installing, but I
| was just amazed that Windows 95 even let me install the driver...or at
| least thinks it did) in 8-bit, I did do the cube and there the Cosmo OpenGL
| (I know it was renamed, but I sure like CosmoGL a lot better... ;^)) did
| beat the MS implementation (by about 20%), although I have to cry that both
| were very, very slow (at about 780 pixels x 580 pixels). It seemed that
| the fill rate was the mail problem. Although I know absolutely nothing
| about this worth spouting my opinions in public, in that case, as the
| shading was absolutely the same on the entire polygon, couldn't you just
| send the polygon to the video card to be drawn? I'm very, very certain the
| video card could draw and fill the polygon in a thousandth or so the time
| it is taking the software to draw and fill the polygon. This wouldn't work
| for other shading models, but it would work for it. Unless the cube demo
| is intentionally doing software fills of polygons.
Well, that's where an MCD comes in - accelerate the modes which can be
supported. We don't bother doing this for Cosmo since a 2D accelerator
doesn't generally support the fragment operations which are performed
per-pixel, e.g. depth test, dither.
Now a question about your test - does your timing loop include calling
glClear and SwapBuffers after each frame? If so you are probably
limited by the speed of the framebuffer clears and the blit, rather
than the actual rendering. Be careful also when measuring the speed of
rendering - if you draw the same object repeatedly with depth function
GL_LESS, it doesn't draw after the first iteration because it fails the
depth test! In other words, you are measuring Z fail performance (e.g.
how quickly does the depth test eliminate fragments?).
| BTW: OpenGL is a remarkably elegant and beautiful product that actually
| makes sense. I do admit wishing there was a bit more speed there, but I
| know that'll come.
We're working on it!
Dennis Forbes
Dennis Forbes wrote:
>Although I know absolutely nothing
> about this worth spouting my opinions in public, in that case, as the
> shading was absolutely the same on the entire polygon, couldn't you just
> send the polygon to the video card to be drawn? I'm very, very certain
the
> video card could draw and fill the polygon in a thousandth or so the time
> it is taking the software to draw and fill the polygon. This wouldn't
work
> for other shading models, but it would work for it. Unless the cube demo
> is intentionally doing software fills of polygons.
Seconds after hitting the post button, I realized all of the complex
matters such as alpha layers, depth layers, etc. etc. etc. that would make
what I asked about unworkable, so I retract this suggestion. Doh!
BTW: If I request a pixel format say 24-bits for a 600x400 window, and
state that I want a 16-bit depth buffer, 8-bit stencil buffer, and an 8-bit
alpha layer (making all this up), does this mean that OpenGL will assign a
piece of memory ((24+16+8+8)*600*400)/8) bytes long in memory somewhere to
accomodate this? Does not choosing double buffering merely allow on to not
have to store the 24-bits of video colour in memory (as its on the video
card), but still the other attribute bits in normal memory? (So even
without double buffering, you have 16+8+8 bits per pixel in normal system
memory) I'm speaking in these instances about a Windows 95 machine using a
normal 24-bit video card.
Also, on a totally unrelated note, does OpenGL have any sort of collision
detection routines?
Michael I. Gold
"Dennis Forbes" <dfo...@execulink.com> writes:
| BTW: If I request a pixel format say 24-bits for a 600x400 window, and
| state that I want a 16-bit depth buffer, 8-bit stencil buffer, and an 8-bit
| alpha layer (making all this up), does this mean that OpenGL will assign a
| piece of memory ((24+16+8+8)*600*400)/8) bytes long in memory somewhere to
| accomodate this? Does not choosing double buffering merely allow on to not
| have to store the 24-bits of video colour in memory (as its on the video
| card), but still the other attribute bits in normal memory? (So even
| without double buffering, you have 16+8+8 bits per pixel in normal system
| memory) I'm speaking in these instances about a Windows 95 machine using a
| normal 24-bit video card.
Something like that. It will allocate the supported configuration which
most closely matches your request, and this often depends on the amount
of VRAM. When you request double buffering it must allocate two color
buffers (but only one depth and stencil buffer). In a software renderer,
it might allocate a DIBSection of suitable size for the backbuffer (and
resize the DIBSection when the window resizes).
Brian Tomas
Michael I. Gold wrote:
>
snip
>
> Its not currently shipped but work to support MCD on Win95 has
> apparently been completed for a couple of months. The paranoid part of
> me believes that Microsoft is holding up its release for "political
> reasons" (e.g. the D3D team is feeling the heat and MS doesn't want to
> "help" OpenGL; just as they are holding up the release of DirectDraw
> support).
>
According to this, it'll be in Memphis:
http://www.microsoft.com/hwdev/pcfuture/graphics/sld202.htm
Regards,
Brian
Richard S. Wright Jr.
The plan was to have this for Memphis, but has since been shelved pending
"feedback". This isn't in print anywhere, but the Microsoft OpenGL
development team will confirm that the DD integration has been postponed.
Richard
Brian Tomas <nume...@wolfenet.com-eschew.spam> wrote in article
<337BFF...@wolfenet.com-eschew.spam>...