PDA

View Full Version : High CPU usage



Moshe Nissim
05-30-2002, 11:51 AM
I run into the following problem with all nVidia linux driver releases:
I am enabling syncing on vblank (setenv __GL_SYNC_TO_VBLANK 1)
My program use doublebuffer visual, and calls glXSwapBuffers
In this case, I expect thatdoing rendering that is not too complex (take substantialy less time than the monitor frame time) to NOT use 100% CPU.
Yet this is exactly what happens.
(It should block-wait (not busy-wait) for the next vblank interrupt.)

[ this question went to nVidia support but was not answered for a long time ]

martin_marinov
05-31-2002, 03:31 AM
Hi Moshe,
I think Eric or someone else posted about similar problem in the Advaced Forum (under Win2k and Nvidia HW). Not 100% sure however, it was long ago...

Regards
Martin


[This message has been edited by martin_marinov (edited 05-31-2002).]

Moshe Nissim
06-01-2002, 09:09 AM
I saw that post. It is old, and doesn't seem to be resolved. In that thread it seems that it was "agreed" that thread-blocking (vs. busy-wait) swapBuffers is the "good thing", but it not done yet. Any idea if its done now on the Windows side? What about linux?

rixed
06-21-2002, 07:20 AM
Im not sure if this is at all possible with linux : depending on your horiz sync frequency, that gives you an interrupt every 20 ms or so. Its possible that the gl driver block-wait untill the interrupt occurs because it can't serve all the drawing work onto the interrupt hadler.
If the interrupt handler had send a signal to the opengl process, the process won't necessary be awaikened by linux before the next interrupt (sheduller swap tasks every 0.1s or so).

IMHO!

Moshe Nissim
06-21-2002, 10:25 AM
[QUOTE]Originally posted by rixed:
Its possible that the gl driver block-wait untill the interrupt occurs because it can't serve all the drawing work onto the interrupt hadler.
?? what do you mean by "serve drawing work onto the interrupt handler?" there is no need to do that..


If the interrupt handler had send a signal to the opengl process, the process won't necessary be awaikened by linux before the next interrupt (sheduller swap tasks every 0.1s or so).

0.1 seconds?!? You are off by exactly one order of magnitude. Default linux kernels are compiled with 10 ms "timer interrupt" (the preemtive scheduling interrupt". This is 0.01 seconds.
You don't have to take my word for it. Try this:
grep timer /proc/interrupts ; sleep 1 ; grep timer /proc/interrupts
and see by how much the interrupt counter has increased during that one second.
You can also check in the kernel source, in include/asm-i386/param.h , look for #define HZ

I even compile my kernel with 0.5 ms , and its works real fine.

FermatSpiral
07-07-2002, 02:36 PM
I don't know why does it work, but my app was using near to 100% CPU, and adding

timespec timereq = { 0, 1 };
timespec timerem;
...
nanosleep(&timereq, &timerem);

before of the render function dropped the usage to near zero when there are few primitives and up to 50% using displaying about 3700 individual triangles with quadratic light attenuation. That is, I asked the app to sleep by a nanosecond before drawing.

Moshe Nissim
07-08-2002, 02:08 AM
Originally posted by FermatSpiral:
I don't know why does it work, but my app was using near to 100% CPU, and adding

timespec timereq = { 0, 1 };
timespec timerem;
...
nanosleep(&timereq, &timerem);
before of the render function


Very interesting.
Where exactly is "before the render function"?
Immediately after glXSwapBuffer() ?
Any glFinish()'s involved there?
Maybe sched_yield() would have the same effect?

FermatSpiral
07-08-2002, 04:47 PM
I have three functions inside main(); begin(), draw() and end(), running inside a loop.

Inside of begin() is glClear() and the transformations code.

Inside of draw() is all the glBegin() and glEnd() stuff.

Inside of end() is glSwapBuffers().

All the other stuff inside these functions is application specific.

The call to nanosleep() is made between begin() and draw().

I have tried with and without glFinish(), the results are the same.

rixed
07-25-2002, 06:37 AM
from Moshe Nissim :

"0.1 seconds?!? You are off by exactly one order of magnitude. Default linux kernels are compiled with 10 ms "timer interrupt" (the preemtive scheduling interrupt". This is 0.01 seconds."

Thats True that the timer is at 100Hz on PCs. But the scheduler do not swap tasks every timer interrupt, but, in average, every 10 or so. So, we come to 0.1s.

(Yes, on PCs there are only 10 different tasks that gets executed every seconds. See "Core Kernel Commentary" for more details).

So, I doubt that you can nonblock-wait for the vertical interrupt without missing at least the next one.

07-29-2002, 07:30 AM
First, let me say that I've just stumbled over this same problem while trying to run two "real-time" rendering applications sync'd to the vertical blank of two TV-out channels on two different video cards.

I also discovered behavior similar to the nanosleep() post using usleep(); however, I believe that the timer resolution issue is still a problem here. Basically, no matter how small a number you specify for the sleep time, you're still sleeping some minimum number of milliseconds (say 10ms or more). At higher refresh rates, this simply causes you to miss one or more subsequent vertical blanks. In my application, this is not good...

The underlying problem is the Linux timer resolution. If I'm not mistaken, there are a few Linux patches/extensions available such as UTIME, KURT, and/or possibly RTLinux which do offer timing resolution reliably down into the tens of micro-seconds. With these extensions, you may actually be able to get some relief by clever use of usleep(); however, this is still a poor substitute for having a blocking-wait.

With the usleep() method and a timer resolution modification, you'd still have to be able to accurately determine your rendering time, usleep() for any remaining time in each vblank cycle, and wake up in time to spin-lock on the glXSwapBuffers() call. Though this may work as a temporary fix, this doesn't sound like much fun to me... especially considering that you've got multiple applications competing over the processor and this may complicate accurate determination of time required to render... thereby causing missed vertical blanks!

Anyway, the correct solution would have to come in the form of a blocking-wait buffer swap instead of the current spin-wait. As noted in other posts, this is not feasible with most (if not all) standard Linux implementations; however, it should be possible in combination with one of the timer resolution modifications available for Linux. So, what I'd like to see is nVidia providing an option whereby the developer could select blocking-wait or spin-wait as appropriate for their application. Spin-wait could certainly be left as default for default Linux users, but I'd like to be able to switch to blocking-wait on my timer resolution modified systems capable of pulling off the scheduling required.

So the question is: does such an option exist to change wait methods? If not, could we have one please??? Hopefully nVidia has and/or will address this issue shortly... would certainly be a big help in achieving my real-time computing goals under Linux!

Anyone been in contact with nVidia on this topic???

Moshe Nissim
07-29-2002, 08:07 AM
Originally posted by ScuzziOne:

The underlying problem is the Linux timer resolution. If I'm not mistaken, there are a few Linux patches/extensions available such as UTIME, KURT, and/or possibly RTLinux which do offer timing resolution reliably down into the tens of micro-seconds.
I work reliably with standard linux, with 0.5 ms timer , simply by compiling the kernel with HZ = 2000. No special extension needed.




Anyway, the correct solution would have to come in the form of a blocking-wait buffer swap instead of the current spin-wait.
I completely agree


As noted in other posts, this is not feasible with most (if not all) standard Linux implementations; however, it should be possible in combination with one of the timer resolution modifications available for Linux.


I disagree. Its possible with different coding in the nVidia driver. Linux is perfectly capable of putting a process to 'sleep' when its doing a blocking wait (select, read, whatever), and wake it up very quickly upon hw interrupt (handled in this case in the nVidia driver kernel module)
Remember that even without modifying timer resolution in the kernel (HZ) the scheduler can still wake up the waiting process exactly on the event (vsync, via interrupt), if no other process is in the CPU. Modifying timer resolution will help preemption. (kicking other process out when vsync arrived and 'our' process is waiting for it). But again, this is just compliation of standard kernel with #define HZ changed -- no patch


Anyone been in contact with nVidia on this topic???

I have. I sent a report to their linux support ... and got zero response :-(

08-01-2002, 01:24 AM
I think this is happening if the program take substantialy less time than the monitor frame time:
The first call to glXSwapBuffers is done the proper way letting the driver wait for the sync using the interrupt. Control is given back to the program that creates another frame and calls glXSwapBuffers. NVidia do not store more than one frame so if the first frame is still waiting should the driver block now. Using the sync interrupt is little more complicated now since it is the first frame that should be called then and not the second. The above works very well if the program does not create frames faster than the sync rate for the monitor. If you let the second frame block-wait will the modified code probably be little worse for the more common use.

Has anybody tried to put in a glFinish()? Perhaps will this function wait in a more polite way.

saian
08-01-2002, 04:13 AM
hi all !!

i'm beginner to opengl, glx and threads and linux...

I tried it myself (so got some problem in another post), i done something like that:

i got one thread that scheduler the whole, and i thread get from window management: rendering and user interactivity...

if i don't ask any thread to sleep some nanosecond, my render crashes.

Rixed sayed: "Thats True that the timer is at 100Hz on PCs. But the scheduler do not swap tasks every timer interrupt, but, in average, every 10 or so. So, we come to 0.1s.
"

I don't think you're right... the scheduler swaps threads or processes related to their priorities. in fact, their effective priorities, that it calculates in relation with their real one.
So, if you have a high priority, your task could be executed some times in a row, so it could looks like it's done just once with a slower rate. i think it's that.

when you make a basic thread with 2 thread just counting, you get more that 10 lines that happears on your screen in a second...
and the linux scheduler manages all other tasks too... as almost here: X.
X could be another pb too.

thanx for reading me !

rixed
08-01-2002, 05:27 AM
saian :

"when you make a basic thread with 2 thread just counting, you get more that 10 lines that happears on your screen in a second"

Of course, if you don't wait for swapping.
Here is a little test for you to see :

---------------
toto1.sh :
---------------
#!/bin/bash
while true;
do
while ! test -e /tmp/toto ; do
echo "wait..."
done ;
echo "thread 1";
rm -f /tmp/toto
done

---------------
toto2.sh :
---------------
#!/bin/bash
while true;
do
while test -e /tmp/toto ; do
echo "wait..."
done ;
echo "thread 2";
touch /tmp/toto
done

---------------
chmod a+x toto1.sh toto2.sh

((toto1.sh &) ; (toto2.sh &)) > output ; sleep 10 ; killall toto1.sh && killall toto2.sh

grep 'thread 1' output | wc -l
-> 123
grep 'thread 2' output | wc -l
-> 122

meaning : toto1.sh was interrupted by toto2.sh 122.5 times in 10s.

Do it with another HZ, you gona have more.

clear ? :-)


[This message has been edited by rixed (edited 08-01-2002).]

08-07-2002, 02:59 PM
I do not have any more speculations about how the driver works but some comments about threads. If you have to call a sleep function to avoid a crash does you code probably have a race condition. It is just the scheduler that is running during the interrupt not the threads and processes.

I also thinks that the assumptions about how fast threads can be swapped is not true. Here is a little hack that gives me a lot more than 1000 swaps each second on a standard RH 7.3 kernel. Remember to build with -D_GNU_SOURCE



#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <pthread.h>

int done;
pthread_mutex_t mutex1= PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t mutex2=PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t m1=PTHREAD_COND_INITIALIZER;
pthread_cond_t m2=PTHREAD_COND_INITIALIZER;

void alarmHandler(int signum)
{
done=1;
}

void *thread2(void *count)
{
int *c=count;

pthread_mutex_lock(&amp;mutex2);
while (!done) {
pthread_cond_wait(&amp;m2, &amp;mutex2);

pthread_mutex_lock(&amp;mutex1);
pthread_cond_signal(&amp;m1);
pthread_mutex_unlock(&amp;mutex1);

*c=*c+1;
}
pthread_mutex_unlock(&amp;mutex2);
pthread_cond_signal(&amp;m1);
pthread_exit(NULL);
}

int main()
{
int thrd2ID;
int count=0;
pthread_t pt2;

done=0;

thrd2ID=pthread_create(&amp;pt2, NULL, thread2, &amp;count);

signal(SIGALRM, alarmHandler);
alarm(10);

/* give the second thread little time so it starts */
usleep(20);

pthread_mutex_lock(&amp;mutex1);
while (! done) {
pthread_mutex_lock(&amp;mutex2);
pthread_cond_signal(&amp;m2);
pthread_mutex_unlock(&amp;mutex2);

pthread_cond_wait(&amp;m1, &amp;mutex1);
}
pthread_mutex_unlock(&amp;mutex1);
pthread_cond_signal(&amp;m2);

pthread_join(thrd2ID, NULL);
pthread_mutex_destroy(&amp;mutex1);
pthread_mutex_destroy(&amp;mutex2);

printf("\nthread2 was swapped %d times in ten seconds\n", count);

return 0;
}

rixed
08-08-2002, 06:53 AM
Of course you can swap between THREADS very quickly. This has nothing to do with the timer interrupt : by doing a pthread_cond_wait or a pthread_cond_signal you implicitely call the sheduler ! So that the number of swaps, in your example, is only limited by your CPU.

I could have achieve the same result in the shell example I gave, if instead of simply touch/rm the file used as a lock, I had connected the two shell scripts with a lockfile.

The point was, if I understood it clearly, how longer a task can run before being interrupted by the scheduler ; so obviously the tasks must not explicitely ask the scheduler to switch task to a specified thread, which is of course done at once :-)

The example I gave do just that : executing a 100% CPU loop and counting, by a trick, how much time these stand-alone CPU hungry processes were interrupted by force by the scheduler.

The scheduler itself is launched by timer interrupt every 1/100s, and actualy swap tasks about 1 times out of 10, so that leads us to the 0.1s of execution time by process I claimed.

Why is that the point instead of thread calling each others ? because we were talking about the vertical IRQ, adding a task for the GLX function that swaps screen, task which is not connected by any signal, as far as I understand the situation, to a given openGL application.
That's why I doubted the nonbusy waiting functionality of GLXswappbuffer.

I may misunderstood the relations between vertical IRQ, GLX and the application, anyway. I tried to disassemble the libGLX, looking for the IRQ handler and the swappBuffer function, without results.

Someone with knoledge of the technical design of GLX could help me...

friendly waiting for your comments,

08-09-2002, 03:16 PM
Sorry if I made your statement more general than intended. I think that you overlook the fact that linux is using preemptive scheduling. According to this page is every process given a fixed time slice of 200ms to run because of that http://iamexwiwww.unibe.ch/studenten/schlpbch/linuxScheduling/LinuxScheduling.html
You can create processes with higher priority that will intterrupt the lower priority task. The man page for sched_setscheduler also describes the scheduler.

The NVidia people know but will not tell us. I guess they find our speculations amusing. http://www.opengl.org/discussion_boards/ubb/smile.gif

Moshe Nissim
08-09-2002, 10:44 PM
The fact that the preemtion interrupt ("timeslice") is X (10 ms in unmodified kernel) doesn't mean processes are swapped exactly at 10 ms boundaries, or swapped every 10 ms. It can be more if the scheduler decides to let the current process keep the CPU. It can be less if a process "voluntarily" yields the CPU by making a blocking system call (select, read, etc.)

rixed: you doubted glXSwapBuffers makes a nonbusy wait?? You think it SHOULD make a BUSY wait?? You can find the top level of the IRQ handler in the nv.c file in the open-source part of the nVidia kernel module. But it doesn't help much, very little is visible there.

For what its worth, I checked the behaviour under Windows (and OpenGL) and its exactly the same.

The fact that the board delivers interrupt at every vertical blanking (it does, I checked) means to me they know it should be done this way (nVidia I mean).
Why they don't do it after all, that's the interesting question

08-12-2002, 10:03 AM
Well,

I personally believe this is a problem with the nVidia drivers/GLX and have sent a bug report to them. Of course, there's been no reply to date. Regardless, I urge any/all who are interested in gaining maximum utilization/performance out of their system (such as in a realtime environment) to send a note to nVidia to let them know you exist. As in all things, "the squeaky wheel gets the grease" and it appears that not enough of us have squeaked yet to warrant any sort of response from the nVidia technical support folks. Given that I've got my reputation on the line with projects pushing real-time linux and OpenGL, I certainly hope nVidia is not on the verge of pulling a 3dfx on us! Don't get me wrong, I appreciate the support they've dedicated to the Linux community thus far... it just concerns me that they seem to feel no need to respond to their Linux tech support e-mail! So, if you're in the same boat with the rest of us, please let nVidia know you exist as a Linux based user.

Perhaps we'll get some sort of response if enough folks e-mail them. Personally, I wouldn't even mind if the response is only to point out that we're all friggin' idiots who don't know squat about coding OpenGL as long as it also points out the error of our ways so that we can move on to happier times.

Hey, our e-mails may be going straight to /dev/null; however, it's worth a try! http://www.opengl.org/discussion_boards/ubb/smile.gif

Thanks

Moshe Nissim
08-12-2002, 10:14 AM
Originally posted by ScuzziOne:
Well,

Given that I've got my reputation on the line with projects pushing real-time linux and OpenGL, I certainly hope nVidia is not on the verge of pulling a 3dfx on us! Don't get me wrong, I appreciate the support they've dedicated to the Linux community thus far... it just concerns me that they seem to feel no need to respond to their Linux tech support e-mail!
Thanks

Just so you know, the problem isn't specific to Linux. A 1 millisecond rendering loop with vsynced swap on Windows (2000 included...) also takes up 100% CPU.
If you search the advanced forum you'll see that this thing has already came up, without resolution (and without a mention of Linux..). The nVidia people seems to go as far as stating something like "we know it should be done differently, but our bosses don't let us release the CPU for fear of loosing even one benchmark point in game engine benchmark (which don't multirhead...)"
In Linux the problem is even somewhat reduced by the fact that you can run the OS at a much smaller preemtive time-slice than 10ms (giving the scheduler a chance to take the CPU from that dreaded nv-driver busy-wait and give it back in time!)

08-12-2002, 12:24 PM
All I can say is that if that is really the official nVidia response, it simply doesn't (or at least shouldn't) "hold water." Fine,
leave the current behavior as a default assuming that the vast majority of users simply aren't competent enough to configure the driver and simply want to play Doom, Quake, or whatever. For the professional market though, I simply cannot believe that it would be that hard to provide a means of switching to a blocking-wait method instead.
Besides, from what I've seen of gamer video card ownership polls, gamers aren't exactly adopting nVidia's latest hardware releases at a blistering rate. To see what I mean, take a look at the survey at:
http://valve.speakeasy.net/

The majority of these folks are still running GeForce2 MX! They certainly don't seem to be all that worried about obtaining the highest possible frame rates... if they were, they'd be moving on to newer cards. Seems to me that the professional market is going to start playing a larger role here in demanding faster/better graphics cards. From what I've seen, we're all "chomping at the bit," for alternative high-end PC graphics solutions other than that provided by SGI. Not that I dislike SGI hardware, mind you, but in my experience SGIs stuff is all or nothing: If you want the graphics, you've got to buy all this other high-end hardware to go with it whether you need it or not. Thus, the poor showing of the SGI PCs from a few years back. When the nVidia guys broke off from SGI, I really hoped they were going to address this segment of the market. I understand that they initially went after the low-budget home-owner/gamer market, but it's time to start looking longer term... Who's going to buy the latest graphics hardware releases with the escalating initial release prices??? Looks to me like it will be the professional market... feel free to correct me if I'm wrong.

And while I'm on my soapbox... could we have 12-bit RGBA please??? Matrox has made the first step with 10-bit... presumably aimed at the DV crowd; however, 12-bit would be greatly appreciated! I know, I know, I ask for too much too soon! For now, I'll settle for a blocking wait on the glXSwapBuffers() call! http://www.opengl.org/discussion_boards/ubb/smile.gif

My apologies for the rant...

Moshe Nissim
08-12-2002, 12:45 PM
in the NVIDIA_kernel-1.0-2960 directory, view the file os-interface.c, and look for 'sgi' and 'swap' (case insensitive)

08-12-2002, 01:24 PM
Yeah,

That harkens back to the early days when SGI was threatening legal action against nVidia for running off with the company "secrets." Best I recall, they settled out of court via some mutually beneficial agreement. Perhaps that's the underlying problem... nVidia's been neutered to keep them from whizzing on SGIs turf? If/when they become available, I bet SGI's Intel-Linux based boxes will support blocking-wait VBLANK synchronization. Funny thing is that if memory serves me well, nVidia is supposed to provided the graphics solution for these platforms. If I'm correct, it will be a tell-tale sign of nVidia's castration if SGIs have blocking-wait while standard Linux drivers don't.

Moshe Nissim
08-12-2002, 01:44 PM
If/when SGI Intel/nVidia-based boxes become available?
There used to be such a line of products from SGI!
But if I'm not mistaken, SGI ceased it. http://www.gotocol.com/sgi.html
Can you find it on SGI's own site? I can't...

08-12-2002, 03:47 PM
Oh, SGI had a PC...

I've actually got a SGI 320 sitting behind me with, I believe, two 450MHz processors and a gig of RAM. Seems like we purchased it somewhere around 1998/1999 time frame for some large chunk of change. Too bad it was saddled with the WindowsNT operating system. I think the big problem back then was that most people eye-balling these systems saw them as over-priced desktops, didn't want to develop under NT, and didn't trust/know enough about Linux system performance/support on these systems. I still don't really know that much about them as that the processors are really too slow for my applications today.

I was also not the original user of this box as that it was purchased to run some third party visual database generation tools. I believe that the hopes were for this box to allow database generation without requiring the horsepower of an Onyx2 system. The folks actually used it for a couple of years before giving it up as too slow. I'm not certain whether they simply bought a new PC to replace it or have moved back to Onyx2 database development.

Either way, it is unfortunate that I did not take the time to investigate this box sooner. At the time, I was tied up with development on Onyx2 systems for which we had paying customers who could afford such systems. We still make use of Onyx2 systems today; however, much more emphasis has been placed on finding cheaper solutions to supplant such systems where possible.

When I got my hands on this SGI 320 a couple months ago, I had to crack it open, of course, to see what wonders lay inside. Basically, it appears to simply be a PC way ahead of its time. Looks like at a minimum, SGI implemented many of the next-generation standards... some of them the likes of which mainstream PCs are only now beginning to sport. Seeing it now, it's actually quite an impressive machine.

I believe it was available with Linux as an option when new; however, nobody here had any desire to forage into the Linux world on this machine at that time. From what I remember, we found it questionable as to what level of support we'd have under Linux with this custom SGI solution. Remember, in those days, hardware acceleration under Linux was a gleam in our eyes... everyone wanted it, open source folks were trying to provide it, there was no DRI architecture, and nobody seemed to have it all together as a 3rd party solution like nVidia has today.

I was under the impression that the video sub-system in the SGI 320 was actually a SGI developed system. From my recollection, seems like nVidia was hardly a blip on the radar back when these systems hit the scene. If I'm mistaken, please point me to the blurb that explains otherwise. Did one of these systems say it had nVidia graphics hardware? If so, which one? I didn't realize that SGI had gone that far with third party graphics hardware vendors and Linux.

Basically, I was under the impression that we were still waiting for the new Intel-nVidia-Linux architecture and that all this development that nVidia has been doing would be applied to that along with SGIs real-time multi-processor know-how. I know we've witnessed much technology flow-down from SGI to the open source Linux community, such as the SGI journaling file system, but I guess I've been under the assumption that there's more going on behind the scenes that we've not yet seen and that will not necessarily be made part of open-source Linux.

Surely SGI is not going through all this trouble without a perceived future goal. Did I miss it already???

Ok, now you've done it! I'm confused! http://www.opengl.org/discussion_boards/ubb/smile.gif

08-12-2002, 03:55 PM
Oh yeah,

Here's the SGI URL:
http://www.sgi.com/products/legacy/intel.html

Moshe Nissim
08-12-2002, 08:21 PM
What confused you is that SGI had a previous line of Intel-based workstations which was quite different (the Visual Workstation line). It did have intel processor, but the motherboard chipset was completely SGI's own, the graphics was in the 'northbridge' (no visible AGP card) and the architecture was unified memory. It also had a nice 'onboard' video IO interface. You can see the like of this machine today in nVidia's nForce chipset. Unlike the SGI PC you see today, it didn't have linux as an option, only WindowsNT and later WIndows2000. As a matter of fact, it had a license from MS to do a modified HAL to support the unique hardware architectuer.
That line was dropped too, when the simpler PC line came (which was based on VIA chipset)
This line (230, 320, etc.) was always based on nVidia-chip board. SGI made the board themselves, much in the same way that Creative, Visontek and many others do. They didn't over-expose the fact that these machine's graphics are nVidia based, but that's what they are. nVidia was hardly a 'blip on the radar' back then. It was already in the GeForce2 era, and 3dfx was already in trouble. The linux drivers SGI used on these boxes was available on the same time for download from nVidia directly (like it is today). Contrary to SGI's claims, I found no difference between the two. Actually, the chipset SGI chose (VIA) gave less AGP stability and performance with the nVidia board then the already-then-available Pentium4 chipset.

Are you confused? Its not my fault! Its SGI that's confused you. Try re-thinking your statement about it 'going through trouble with perceived future goal..." :-(


[This message has been edited by Moshe Nissim (edited 08-12-2002).]

Moshe Nissim
08-12-2002, 08:25 PM
Originally posted by ScuzziOne:
Oh yeah,

Here's the SGI URL:
http://www.sgi.com/products/legacy/intel.html

Note the URL has "legacy" inside its path...

Note this too: http://support.sgi.com/nt/product/230/
download the "NVidia Display Flash BIOS for VR7"
unzip, and in the readme.txt see:

SGI Quadro2 Pro BIOS. Also called VPro VR7

08-13-2002, 07:45 AM
Darned if you don't learn something new every day! I did not realize that SGI and nVidia had already collaborated on previous boxes. Makes sense though. Ignoring my current projects, the last time I worked a Linux project both nVidia and 3dfx were pushing for accelerated hardware support under XFree86. XFree86 was working towards their loadable drivers release (4.0, I believe) but was not quite ready to release it yet. To my recollection, OpenGL hardware acceleration prior to modules was a bit qwerky... making use of Mesa along with a combination of other libraries from SGI, nVidia, and the open source community. 3dfx was in the fight at the time; however, in my personal opinion, 3dfx had hit "rude" tech support mode by this point and I wanted nothing to do with them. We did end up successfully using an nVidia card to complete the project. I then went back to Onyx2 land for some time until recently when I saw an opportunity to push Linux as a viable solution again. Many improvements have been made with loadable module support, etc.

Anyway, it was my opinion of earlier times that SGI was only half-heartedly chasing the Linux support. Within the last year we've seen a lot of signs that SGI's investment in Linux is increasing. This is what leads me to believe that SGI will be putting out a much better supported Linux box with some level of SGI real-time capabilities approaching that of which we have on the higher end SGI systems such as the Onyx2. Again, this level of Linux support is purely my speculation... we may end up being sorely disappointed. I also had the impression that nVidia would be the primary graphics provider for this new effort... again, I could be wrong. Whatever the case, new systems are coming. Take a look at this press release:
http://www.sgi.com/newsroom/press_releases/2002/july/itanium2.html

I believe these are the future systems to which I was referring previously. Seems like nVidia is the most likely choice for graphics hardware given their buildup of accelerated hardware support under Linux. I believe we'll see a more cohesive Linux support push here. Of course, only time will tell as it is my opinion that SGI has been having trouble deciding which way to run lately!

Moshe Nissim
08-13-2002, 10:13 AM
I think this anouncement is irrelevant to graphics solutions, nor to "PC-like architecture". Note the keywords: "computing server" , "shared-memory system architecture", etc.
Its along their roadmap to put Intel I64 CPUs into their Origin/Onyx system architecture. I think, though, that their original plan was to use Intel I64 instead of MIPS processors much earlier than now, but sadly Intel missed their schedule and SGI was stuck with under-invested (and under-developed, therefore under-performing) MIPS processors today

08-18-2002, 01:51 AM
A lot of different topics in this thread. http://www.opengl.org/discussion_boards/ubb/smile.gif
About the 10-bit RGBA from Matrox do I think they use some bits from the alpha channel so you get 10+10+10+2 RGBA. I just read some stuff from John Carmack and he said the next step should be 64 bit RGBA. I guess that means 16+16+16+16. Probably needed in the future if many passes becomes common. Here is the slashdot link for Carmacks presentation
http://slashdot.org/articles/02/08/18/015214.shtml?tid=127

Tuna
08-24-2002, 06:10 AM
Folks,

Just to clarify, I work (with RedHat 7.3) on one of those "legacy" boxes. They did indeed sell them with linux, and they did have Nvidia cards, and a special hardware GL driver.

I still work with it (dual 800 xeon), and now the driver we use is the standard Nvidia/XFree86 driver, downloaded off the website.

At any rate, yes they did sell as linux boxen,

Tuna

PS,
When we were using the "special" driver, there were definite bugs(like not being able to access all 1GB of memory, only ~860M, crashes during GL programs, etc.). Definitely bleeding edge. I have no idea whether it supported the blanking you're referring to.


[This message has been edited by Tuna (edited 08-24-2002).]