[quake3] How far can SGI MIPS, Sun SPARC, and LinuxPPC go?

Patrick Baggett baggett.patrick at gmail.com
Thu Apr 10 02:24:12 EDT 2008


First, a little sheepish about the being considering the "SGI MIPS" interest
for IOQuake3...

As far as graphics go, I've got 3 main systems I am interested in:

a) Indigo2 R10000 with Max IMPACT graphics + 4MB texture memory. RAM = 1GB
and CPU = 195MHz
b) Octane R10000 with MXE graphics (also 4MB texture memory). RAM = 1.75GB
and CPU = 250MHz
c) Octane2 R12000 with V8 graphics (108MB texture memory). RAM = 2.0GB and
CPU = 350Mhz.

Anything less than a) probably won't run it at all. Anything more than c)
will definitely run it well, as is.

The MXE graphics, which have 4MB of texture memory and still play IOQuake3
at decent FPS, but it isn't exactly a beautiful 60 fps all the time as you
can imagine, something more along the lines of 15-25FPS at 800x600. I
actually haven't tried the Indigo2 Max IMPACT yet, but it is the same as MXE
just with a slightly slower bus and 17% less clock speed on graphics card --
likely to be playable but not super. The V8 works great ~40-60FPS at
1280x1024 at 30bpp, depending on scene. It's bigger brother on a Fuel (R14000 @
600MHz, 1.5GB RAM), the V12, plays extremely well in my opinion. I've got
another Octane2 with V6 for medium range testing, and it seems to work well
too. As far as servers go, I run IOQuake3 ded on Challenge L with 12xR10000
@ 195MHz and it works great.

Note that none of these support anything more than OpenGL 1.2 in hardware.
No shaders, no multitexturing, nothing. As you can imagine, fill rate at the
absurd resolutions that SGI machines love such as 1280x1024 becomes a real
problem.

I personally think IOQuake3 shouldn't drop/compromise support for older
platforms in favor of new graphics candy. I figured IOQuake3 was focused on
being a stable, mature, and bug fixed version of retail Quake3. It certainly
does so in the backward compatibility. I just don't care for new graphics.
Trying to retrofit new graphics onto what was designed as a fairly fixed
function (at the core) graphics engine kind of seems a step in the wrong
direction. Some people may enjoy seeing stuff like that done, but I'm just
trying to have something to play with. Quake 3 everywhere, basically. SGI's
graphics cards weren't really designed for heavy texturing, so these games
are usually fill-limited -- they're optimized for things such as line
drawing, NURBS eval (max evaluators is 36, compared to GL's 8), and display
lists (actually compiles some display lists into GPU microcode.) Quake3 is
pretty taxing on them as is.

As for the future:

My steps are small, but I've been working on a tiny library called libMIPS
that basically is a runtime in-memory assembler. I was going to take some
select instruction generation functions and add a MIPS dynamic compiler
(vm_mips.c) . For example, to create a function to load r4 with the value
0xAABBCCDD, I'd write:

code32[0] = MIPS_lui(4, 0xAABB);
code32[1] = MIPS_ori(4, 0xCCDD);

function = (func_ptr)code32;

function(); /* execute these instructions */

As far as extending IOQuake3 to use things such as IPv6, SMP, I think that
is a great idea. IRIX supports IPv6, and I've got a number of dual-processor
machines that I wouldn't mind testing with. I've been working to optimize
and trim Quake specifically for IRIX actually (dubbed unsurpisingly,
irixquake), and some of the things I've been researching include running
sound/sound mixing code on its own thread. It isn't fully complete right now
(bit hacked, actually), but for software quake, the benefits are decent
enough. This isn't really an issue for devices that do hardware/kernel
mixing, or under Win32 where DirectSound automagically creates a thread for
you, but when you're running on a dual processor 250MHz machine, it helps to
use every ounce of CPU you have available. Also, the standard sound card in
most of the SGI machines does no mixing/spatialization in hardware. It's
just a DMA device, really.

Vincent, I also have a 4x400Mhz Sun E420 + Expert3D (128MB) + 4GB RAM if you
need some low end testing. I've compiled IOQuake3 using your makefiles
(though I used Sun's C compiler, not GCC since GCC/sparc is pretty meh). My
preliminary tests (aside Solaris's OpenGL bugs) show performance to be
similar to SGI's old stuff. I run in a 800x600 window.

If I didn't answer any questions, please let me know.

Patrick Baggett

On Wed, Apr 9, 2008 at 7:28 PM, <monk at rq3.com> wrote:

> This is mostly directed to those who have access to these platforms or
> know them well enough in relation to ioq3.  I'm guessing...
>
> tjw and Mattias Nissler = LinuxPPC
> Vincent = Solaris SPARC
> Patrick Baggett and "Mare" = SGI MIPS
>
> You guys have probably seen some of the recent discussion about improving
> ioq3 in terms of graphics and other features.  What are your thoughts?
> I'm assuming those listed platforms aren't going to have performance
> issues with things like UTF support and skeletal model support.  But maybe
> some issues with, say, the semi-recent framebuffer work that added bloom
> effects?
>
> How much does ioq3/q3 chug along currently, 10 fps, 60 fps?  Can your
> hardware handle stuff that will make the game look more pretty, or are you
> about your limit for pushing pixels?
>
> If the ioq3 devs decide to eventually set a cutoff for features as a
> legacy release, it'll probably be you blokes who can tell everyone what's
> practical to include as features and what won't work at all.
>
> Monk.
>
> ---
> To unsubscribe, send a blank email to quake3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20080410/c8912925/attachment.htm>


More information about the quake3 mailing list