Parallel Mesa
An anonymous reader writes "Some French students have started to code a parallel version of Mesa 3.0 (PMesa).
They can reach a very good speedup (between 1.2 and 1.8). " SMP and OpenGL?
Neato. That Mesa Quake thing is looking smoother all the time.
Not that parallel Mesa isn't cool, but I'd go for hardware excelleration anyday.
More to the point, they get a speedup of 1.8 on a dual processor. Meaning Mesa is highly parallelizable.
When compiling Mesa, one of the options is to 'make linux-pthread'. Is this option making the library more parallel or what?
More to the point, they get a speedup of 1.8 on a dual processor. Meaning Mesa is highly parallelizable.
but will it speed up 3dfx Quake II upto NT's framerates? prolly not...
On fast processors Q2 under Linux on Voodoo 2 using mesa, is already faster then under 95.
Even on slower computers, the miniport isn't far off.
1.8x speedup? This should blow away the NT numbers.
What about hacking Quake itself for a parallel processing environment?
Now THAT would be cool acceleration: Quake2 on a BeoWulf w/ a Gigabit Ethernet.
Actually, Voodoo2 based Glide Quake2 performs at
higher framerates in Linux, than in NT. As does
RivaTNT based OpenGL Quake2.
Digital, avail. either 32bit or 64bit.
Yes, the ideal situation is an onyx2 from sgi, but barring that, most of us will have to settle for something along the lines of a 3dfx voodoo/banshee, whatever. Since the 3dfx chipsets do mostly rasterization, much of the triangle setup must be done on the host cpu. It turns out that oftentimes a graphics setup is not fill rate limited, it is limited by how quickly the host can supply the graphics hardware with the appropriate information. This is especially true if you have more than one board, say with SLI. So parallelization of the work that does have to be done on the host can oftentimes speed things up even in a hardware accelerated context.
Something tells me this is futile :)
Has someone written a pthreads wrapper that will distribute the work over a beowulf-class machine? And what will you do about bandwidth between CPUs (which is much worse over ethernet than across an internal bus?
I don't know where people got this funny idea, Q3A does not have SMP support. Carmack said that he tried it, but didn't see any usable performance increases. Something on the order of 5%. That 5% probably wouldn't be portable and apply to linux anyways.
Erm.. you didn't read the article, did you? The increase of 1.8 was found on a dual p-2 400 with a voodoo 2 card. This 1.8 increase is with hardware acceleration.
Those who had chance to do so could spot his explanation on how he tried to make rendering faster on two processors, I don't want to repeat what he did, but he failed. It seems one can't make real time rendering faster on few processors,
it's too slow because of shared memory. Grr...
Not to sound stupid, but does that mean any Riva TNT based card will be able to use Creative's driver?
There were some linked off mesa's site.
Or maybe it should be because so few of us just read e-mail and browse anymore... you can do that with a 486 and 3.11
SMP is obviously for the REST of us...
Um.. what are you talking about... how did you get RivaTNT based OpenGL Quake2 for Linux? Or did you get your first sentence turned around?
Doesn't BeOS already do that? Or is this something different?
When you render a triangle, you first have to do all geometry transformations, then you have to calculate the 2D points of the triangles, texture coordinates, texture perspective correction values, delta values, etc. The card helps with calculating the coordinates and delta values needed for the hardware to render it at the very last stage of the pipeline, but does no 3D transformations- it just helps with the 2D calculations needed to go from a 3 point triangle (with texture and Z info) to the data the hardware wants.
What we want is to be able to feed a triangle's 3d points and texture values, tell it which matrix we are using, and have it do all the work for us.
Anyone manage to actually download the distribution? None of the links to the software seem to point to anything..
When are these hardware manufacturers going to learn that you make money off of the hardware, not the drivers. Boycott all hardware vendors that won't release drivers/specs. Maybe if we hurt 'em in the pocket book, they'll get a clue. We may be a minority now, but in a few years, a linux community boycott is going to hurt some of these vendors right where it counts, in the pocket book!
Boycott all hardware vendors that won't release drivers/specs. Maybe if we hurt 'em in the pocket book, they'll get a clue. We may be a minority now, but in a few years, a linux community boycott is going to hurt some of these vendors right where it counts, in the pocket book!
When are these hardware manufacturers going to learn that you make money off of the hardware, not the drivers. I guess it takes a rocket scientist to figure out that you will sell more boards if you give people the drivers to run them on their OS.
Boycott all hardware vendors that won't release drivers/specs. Maybe if we hurt 'em in the pocket book, they'll get a clue. We may be a minority now, but in a few years, a linux community boycott is going to hurt some of these vendors right where it counts, in the pocket book!
There's already a parallel version of Mesa that's
MPI-based. See http://www.cs.sandia.gov/VIS/pmesa.html
for more info.
Linux is the OS of the future... Maybe because it is the only one who have nuts people enough to make everything parallel!
hmm.. BULLSHIT
Those who had chance to do so could spot his explanation on how he tried to make rendering faster on two processors, I don't want to repeat what he did, but he failed. It seems one can't make real time rendering faster on few processors, it's too slow because of shared memory. Grr...
You forgot the part where he said that what he did was a quick hack, and that he would actually be making an explicitly threaded renderer for Q3 instead of just threading the game..
You can read it again here...... http://finger.planetqua ke.com/plan.asp?userid=johnc&id=9801
Bob Black
I run Quake II using the lib3dfxgl.so which is much faster than libMesa or rendering in a window (which is a hack anyway)
It uses SVGAlib for keyboard and mouse handling but I don't think it uses it for any kind of 2D work. I can't see why there would be any 2D anyway.
RedHat and Precision Insight are working on Multipipe Direct Rendering (MDR?). This will enable multiple processes to do simultaneous rendering to X windows. The reference implementation is going to use Mesa with sample hardware accelerated drivers.
What would be very very nice would be:
(1) AMD K6/K7/3DNow acceleration added to the Mesa
subsystems. The 3D acceleration provided here does 3D object transforms, which unknown to many consumers, is rarely done on the graphics accelerator.
(2) The French MESA patches for parallelism. I hope this isn't too hard to coordinate with the Multipipe folks.
With regards to the aforementioned Beowulf extensions for parallel MESA, I think the network connections would be the major bottleneck even at 100mbit speeds. It might be interesting though to push the object transforms out to Beowulf since they are not graphic intensive. Just push out the geometries and return the rotated/scaled/clipped objects. This would help quite a bit on complex worlds.
jim burnes
Why would you plug another celeron 300a into your SMP board? Unless you take a soldering iron to it it won't be much use.
when I do "cat /proc/cpuinfo" it reads over 1000 bogomips.
the 3d output from quake, quake2 is dumped directly thru Mesa, lib3dfx or some other gl lib, but the input (keyboard, mouse) is handled by svgalib. (and yes, you can use all 3 buttons on 3 button mouse in quake)
To lazy to login,
Dj-Ohki
Actually I know what bogomips are, and they aren't a true measure of speed, a P200MMX and PPro200 are both 200 bogomips but I can tell you what one I would prefer by far.
The fact that I have 1005.98 bogomips total on a dual PII system is quite cool though.
Quake doesn't really do that much 2D, and glQuake does no 2D. Everything goes via the Voodoo, I don't think you even need a 2D card to play glquake under Linux. Not that I have actually played glquake under Linux, but there is no need for a 2D card, since the Voodoo card is directly connected to the monitor.
No, the output comes directly from the Voodoo 2 board. That's why you have a pass through video cable. No need for a 2D board except for for 2D graphics work. Of which there is none in glquake.
I've been thinking of building an SMP box, and parallel Mesa is sounds like another good reason... Anyone tried the SMP mod to celeron A's?
--------- Webmaster, http://www.cpureview.com and
The Voodoo][ doesn't use X or svgalib, but rather Mesa (accessing Glide), or a Quake-specific GL miniport.
If it's a 3D-only Voodoo card, it completely takes over when active. The 2D card is completely uninvolved.
Posted by ArtB:
I've run the BeOS GLteapot (software) demo on my Duel PII-450.
With no other programs running BeOS's CPU monitor "pulse" reports one processor at 100% and the other at 0%. When I start another program, or even just move the mouse, the teapot load seems to jump back and forth between both cpu's.
I'd assumed that this showed that the BeOS software renderer was single threaded.
I believe that 1.8x gain was with the hardware-accelerated version. (Voodoo2)
If they want to work on paralell Mesa, let them do so, so it's ready when a manufacturer gets a clue and releases specs.
retrorocket.o not found, launch anyway?
Sort of. I believe the V2 does have a bit of geometry setup assistance, but not much. The host CPU is still the limiting factor in most cases.
retrorocket.o not found, launch anyway?
Um, Quake source is only available if you have a few hundred kilobucks to license the engine from id with. Doom source is out, but that's it.
retrorocket.o not found, launch anyway?
See if you can duplicate that Microsoft!
I don't see any reason why everything shouldn't be SMP nowdays.
"Reactionaries must be deprived of the right to voice their opinions; only the people have that right." - Mao
It may be a bit spendy to have an SMP system *today*, but imagine how much money you could save on upgrades.
/proc/cpuinfo
You could fork out $700 for a pentium III, or you could plug another $80 Celeron 300a into your SMP board. (mine was only $100 more than a regular PII board)
cat
-- 600 bogomips thankyouverymuch.
"Reactionaries must be deprived of the right to voice their opinions; only the people have that right." - Mao
3Dfx/Mesa directly supported by X and the window manager.
Rasterman? Are you listening?
"Reactionaries must be deprived of the right to voice their opinions; only the people have that right." - Mao
Which makes it mondo cool.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
(sorry about previous header, apparently hitting return after the subject posts the message!)
Anyway, this can be easily demonstrated by linking the same program with Mesa or with OpenGL on an SGI Irix machine. If you then run them both: well yes, of course the hardware is faster, but try a program that uses something that the hardware does not do (on mine, any texture mapping) and you will see that Mesa's software emulation is MANY TIMES faster than SGI's.
Perhaps SGI purposely maimed theirs to encourage people to buy more hardware, but I really suspect the reason is that the software writers there are not as good as the ones who work on Open Source.
Good. As soon as our 4x100 ethernet cards show up, I'll see how it performs on a Beowulf, probably will only take minor tweaking. Something tells me there'll still be a need for more bandwidth. =]
Hardware acceleration is still dependant
:)
on the cpu to feed it the data to display.
Indeed for many accelerator cards the CPU
not the card is the bottleneck as even
the the fastest CPUs cant really supply
enough data to max out a top end accelerator.
Thus adding a second CPU to the mix can
offer a massive speedup. I cant wait
to get home and try this on the dual PII 400.
Le'Sigh...
:) Better yet, if
If only Mesa supported RivaTNT's... the graphics
processors on those could probably do a good
amount of graphics churning.
all PCI/AGP slots in a system were RivaTNT's...
heehee...
RivaTnT Render farm? Nah...
- Wing
- Reap the fires of the soul.
- Harvest the passion of life.
- Wing
- Reap the fires of the soul.
- Harvest the passion of life.
It runs at least as fast under linux as it does under win9*. I have a k6-233 and a 12mb voodoo2, and it uses svgalib, no X. Of course right now it's the only decent game I can run under linux, but the future looks bright!
Actually 3DFX support is planned for R4.1. See http://www.benews.com
-= This is a self-referential sig =-
Only if you are doing 2d graphics...like X. Quake does only 3d (basically)...which is why your voodoo (do you have even have one?) switches off your 2d card's output to the monitor when you play games through it.
Likewise, you can have a dual-headed display. One card and monitor for regular 2d stuff like X, and a voodoo with a different monitor for 3d. In this setup...it should be obvious that the 2d card has no effect on the output of the second(3d) monitor. hence...you only need a 2d card to do 2d stuff...you don't need one for 3d voodoo.
or something like that...sorry that was kinda long winded....i've been at work far too long...I'm going home.
"...Beer..."
Carmack had trouble trying to have one processor do opengl calls and the other processor do everything else... there was just too much overhead. What he said in his .plan was that he would just go back to natively threading it, because doing that he saw a fairly linear increase in performance. So, Q3, should have a threaded executable that will run faster on SMP machines, as well as a regular executable for UP machines.
He said, "You'll be able to tell your grandchildren that you helped assemble the first NT supercomputer," and I cringed.
I got an email back from Jon Taylor the man hired
by Creative Labs to do the linux driver work.
He told me that he'd like to see all cards
supported but can't imagine Creative Labs will
pay him to help out the competition, and fair
'nuff I suppose.
And the typical graphical web browser could certainly benefit from multithreading...
You really don't know what a Beowulf is or how you program it, do you?