OpenGL on "oldish" SGI machines
John Tsiombikas (Nuclear / Mindlapse)
about to write a small program for an old O2 system, and I have a vague
idea about the capabilities of the hardware at this point, and no easy
access to a machine to run a lot of tests (I have an old indy at home
but that's not really representative I guess).
Anyway, since my experience with OpenGL comes from PC graphics hardware,
I was thinking how many of my usual assumptions about the efficiency of
various OpenGL features hold on an O2. Specifically, is it also faster
to use textured quads for "blitting" images rather than using
glDrawPixels or not? (considering the O2 UMA and all)
I would appreciate any tips for similar considerations where assumptions
might be different between PC and SGI gfx hardware.
--
John Tsiombikas (Nuclear / Mindlapse)
nuc...@siggraph.org
http://nuclear.demoscene.gr/
jbwest
"John Tsiombikas (Nuclear / Mindlapse)" <nuc...@siggraph.org> wrote in
message news:slrndtat5k...@nuclear.dnsalias.com...
I seem to remember that the O2 has a asynchronous texture loading
capability. So you can be loading one while doing other stuff with the
other.
jbw
Dave Eberly
message news:slrndtat5k...@nuclear.dnsalias.com...
> about to write a small program for an old O2 system, and I have a vague
> idea about the capabilities of the hardware at this point, and no easy
> access to a machine to run a lot of tests (I have an old indy at home
> but that's not really representative I guess).
>
> Anyway, since my experience with OpenGL comes from PC graphics hardware,
> I was thinking how many of my usual assumptions about the efficiency of
> various OpenGL features hold on an O2. Specifically, is it also faster
> to use textured quads for "blitting" images rather than using
> glDrawPixels or not? (considering the O2 UMA and all)
>
> I would appreciate any tips for similar considerations where assumptions
> might be different between PC and SGI gfx hardware.
My SGI O2 reports it is running only OpenGL 1.1. Any program
with textures crashes, but those using only vertex colors
run fine. If you discover the way that an O2 is intended
to do texturing, I would appreciate knowing it. For now
the only reason I keep this machine is to verify that my
source code compiles on an SGI machine (for a customer
who uses my code on an O2, but not for graphics).
--
Dave Eberly
http://www.geometrictools.com
jbwest
"Dave Eberly" <dNOSPA...@usemydomain.com> wrote in message
news:aXgBf.5439$vU2....@newsread3.news.atl.earthlink.net...
O2's definitely DO do textures, indeed quite well for machines of their age.
Extensions Supported by O2 Systems
O2 systems currently support the following extensions:
a.. Pixel Extensions: EXT_abgr, EXT_packed_pixels, SGIX_interlace
b.. Blending Extensions: EXT_blend_color, EXT_blend_logic_op,
EXT_blend_minmax, EXT_blend_subtract
c.. Imaging extensions:. EXT_convolution, EXT_histogram, SGI_color_matrix,
SGI_color_table
d.. Buffer and Pbuffer extensions: EXT_import_context, EXT_visual_info,
EXT_visual_rating, SGIX_dm_pbuffer, SGIX_fbconfig, SGIX_pbuffer
e.. Texture extensions: EXT_texture3D, SGIS_texture_border_clamp,
SGIS_texture_color_table, SGIS_texture_edge_clamp,
Supported only on O2 systems: SGIS_generate_mipmap,
SGIS_texture_scale_bias. These two extensions are not discussed in this
manual.
f.. Video and swap control extensions: SGI_swap_control, SGI_video_sync,
SGIX_video_source.
see also:
for lots of caveats/suggestions about best framebuffer setup, optimal
texture types, & etc.
such as:
"The following texture formats are supported directly by the graphics
hardware and require no conversion when specified by the application:
a.. 8 bit luminance or intensity
b.. 16 bit luminance-alpha (8:8 format)
c.. 16-bit RGBA (5:5:5:1 format)
d.. 16 bit RGBA (4:4:4:4 format)
e.. 32 bit RGBA (8:8:8:8 format)"
jbw
John Tsiombikas (Nuclear / Mindlapse)
> see also:
> http://biology.ncsa.uiuc.edu/library/SGI_bookshelves/SGI_Developer/books/OpenGLonSGI/sgi_html/ch16.html#id16.specialtune58
>
> for lots of caveats/suggestions about best framebuffer setup, optimal
> texture types, & etc.
Thank you very much, most insightful!
p.s. I've also read that due to the unified memory architecture of O2,
stuff like using a video stream as a texture in an OpenGL object are
done without any copying of data! I won't need such a thing, but it
sounds impresive nonetheless :)
--
John Tsiombikas (Nuclear / Mindlapse)
nuc...@siggraph.org
Dave Eberly
"jbwest" <jbw...@comcast.net> wrote in message
news:a-CdncVI14Y...@comcast.com...
> O2's definitely DO do textures, indeed quite well for machines of their
> age.
<snip>
Thanks. Maybe my OpenGL rendering code is using some
OpenGL 1.2 (or later) calls instead of using the EXT versions.
Since my O2 reports it is only OpenGL 1.1, a call just to
query GL_MAX_TEXTURE_UNITS does nothing.
jbwest
hmm, yeah, 1 texture unit I think. Hardware accelerated, but you'll need to
go multipass I think to get multitexture effects. Wow, has it been that long
ago?
jbw
fungus
>>> O2's definitely DO do textures, indeed quite well for machines of their
>>> age.
>>
They weren't amazingly fast at it but they
could have loads of textures in memory thanks
to the unified memory architecture.
At the time all the other SGI machines had
separate texture RAM and it was only 4 or 16
megabytes, depending on your options. Texture
RAM was amazingly expensive. I think I once
paid $5000 for a couple of megabytes of it.
SGI certainly knew how to charge in those days.
A full-blown ONYX would have set you back half
a million bucks and would have been about as
powerful as a GeForce2/Pentium3 machine.
Then there was the RealityMonster machines. You
could spend tens of millions of $$$ on those
things if you really wanted to and a mid range
PC graphics card could keep up with them graphically
(though they wouldn't do it with 48 bit color and
64 multisamples/pixel).
In terms of disk and memory bandwidth one of those
SGI machines would still be orders of magnitude
faster than a PC though, and that's what really
counts when you're tackling big problems.
>> Thanks. Maybe my OpenGL rendering code is using some
>> OpenGL 1.2 (or later) calls instead of using the EXT versions.
>> Since my O2 reports it is only OpenGL 1.1, a call just to
>> query GL_MAX_TEXTURE_UNITS does nothing.
>>
Yep. The query only works if you have a "multitexture"
extension.
> hmm, yeah, 1 texture unit I think. Hardware accelerated, but you'll need to
> go multipass I think to get multitexture effects. Wow, has it been that long
> ago?
>
Yep. One texture unit. SGI was dabbling in some
sort of "detail texture" at that time but there
was no real multitexture.
--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.
In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again. They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens
every day. I cannot recall the last time something like
that happened in politics or religion.
- Carl Sagan, 1987 CSICOP keynote address
jbwest
"fungus" <uma...@SOCKSartlum.com> wrote in message
news:OHVBf.159146$US....@news.ono.com...
> jbwest wrote:
>>>> O2's definitely DO do textures, indeed quite well for machines of their
>>>> age.
>>>
>
> They weren't amazingly fast at it but they
> could have loads of textures in memory thanks
> to the unified memory architecture.
Boy, It;s hard to remember. Polygon rate is certainly a lot lower than
today, but you can do a lot of video stuff on O2's and with fast SCSI
drives, you can stream process pretty well, and I think texture objects
could be paged in pretty darn quickly.
>
> At the time all the other SGI machines had
> separate texture RAM and it was only 4 or 16
> megabytes, depending on your options. Texture
> RAM was amazingly expensive. I think I once
> paid $5000 for a couple of megabytes of it.
>
> SGI certainly knew how to charge in those days.
> A full-blown ONYX would have set you back half
> a million bucks and would have been about as
> powerful as a GeForce2/Pentium3 machine.
>
> Then there was the RealityMonster machines. You
> could spend tens of millions of $$$ on those
> things if you really wanted to and a mid range
> PC graphics card could keep up with them graphically
> (though they wouldn't do it with 48 bit color and
> 64 multisamples/pixel).
>
> In terms of disk and memory bandwidth one of those
> SGI machines would still be orders of magnitude
> faster than a PC though, and that's what really
> counts when you're tackling big problems.
>
Yeah, I know it. One of my customers is still writing code for it (ONYX4),
and most Major Oil Companies have lots of big Onyx's. And I do mean big: up
to 512 Gigabytes of RAM in a very large shared-memory SMP configuration.
Woof, that cost a dollar or two... I guess the maintenance is what keeps the
lights on (dimly) at what's left of SGI....
fungus
>
> I guess the maintenance is what keeps the
> lights on (dimly) at what's left of SGI....
>
Standard maintenance used to be 25% of the
cost of the machine per year. For a million
$$$ machine that's $250,000 maintenance per
year.
Then there was "3 hour response"...