A quick search at yahoo revealed a couple of Dungeons and Dragons fansites. At least one of them had a link to this site which should be interesting to you. It has the script of the last episode that was never produced: http://www.mindspring.com/~michaelreaves/D&Dpref ace.html
And btw, If I was a moderator I would moderate you down to (Score:-5 Spoiler...):)
Well, if something falls into the event horizon the hole will grow.
But so will anything else if something hits them. The earth for example is constantly bombarded with particles from space.
Consider a star with the mass m and radius r. Then consider a black hole with the same mass.
At the distance r from the center of that black hole you would feel exactly the same gravitational pull from the black hole as you would feel from the star if you were standing on its surface.
The difference is that the gravitational pull of the black hole keeps increasing if your distance is less than r. This is in contrast to the gravitational pull of the star if you are inside it. (Since you have lots of mass around you pulling at you you can no longer simplify the star as a point formed gravitational source.)
So, you would actually have a harder time getting a black hole to grow as opposed to getting a star to grow since objects can pass closer to the black hole without crashing into them.
(Allright, some inaccuracies in this post, a star does not have a surface you can stand on, and it also loses mass by emitting energy, etc, but that isn't the point of the post)
I used a Solaris port of IE at one time and I was not terribly impressed. I don't think they would do a better job with the Linux port than with the solaris port.
Now, if Matrox would only release the warp specifications so that we could make secure direct rendering without a performance hit.
Some background: The G200 and G400 has the ability to read and write to buffers in primary memory. This is a great feature, but if misused you can easily crash your computer or with a little more work do things like read and write kernel memory. Therefore we only allow root to do direct rendering in Utah GLX.
Thanks to Matrox' donation of the warp microcode we can now send a list of vertices to the card instead of having to manually calculating things like delta x and delta y values. (This is usually called triangle setup.) This was a great performance boast and also a key to more security since you cannot embed register writes in such a list of vertices.
Still, every time you want to change the current texture or change your current blending mode you will need to write to a register. And since the G200/G400 doesn't distinguish between a register write to change your blending mode and a register write that initiates a blit that will zero out the first 6 MB of framebuffer memory you a normal user cannot be allowed to write such data directly to the card. [1]
You can work around this by sending a buffer with some sort of bytecode to the kernel and let it do some sanity checks on it before sending it to the card. Thankfully the vertex lists cannot contain hidden register writes. [2]. This does not come without a performance penalty though.
What we could do if we had warp specifications is to write microcode that would take a buffer that not only contained vertex data but also information about all mode changes that was safe. Stuff like buffer allocation would still have to be done by the kernel or the X server, but you wouldn't have to do that very often.
I am not totally unreasonable, even though I would love to write some microcode myself I would be satisfied if Matrox provided microcode with this kind of functionality.
Still, this is a problem that will probably disappear in a couple of graphics card generations once multiuser systems is more common.
[1] Actually, the data isn't written directly to the card in any case if you are using DMA to transfer the commands from the host to the card. This is a key to high performance graphics in combination with the G200/G400.
[2] You can upset the card by writing improper values to the vertex list with the current microcode, you shouldn't be able to do more than a DOS attack with it though. The kernel or X server could probably detect this and restore the state of the card if this is tried as well. (I don't know if this is possible, but I think this is the case.)
Actually, I think it would be much easier to program a minimal interpreter in assembler.
Most programmers would have scant problems coding an interpreter from scratch. A compiler however is a different beast, and you wouldn't want to do that in assembler if you could avoid it...
Anyway, I think the first compiler was one of the most important computer related hacks of all time.
Doing a search for geforce on www.linuxgames.com revealed this snippet from an irc log: ----------- ([Jar]2) (orlock) WIll they still be supporting Xfree86/Mesa3D/glx/linux/etc like they have in the past? (nvdaNick) Yes.
(MicroDooD) (LaRz17) Will drivers for multiple operating systems be released at the same time? (nvdaNick) As for driver releases, I think NVIDIA is planning to release all drivers at once.
([Jar]) (MfA) Will the non windows drivers be open source? (ie not run through the pre-processor) (nvdaNick) What would you want with open source drivers, by the way? (nvdaNick) I'm not sure what our plans will be regarding that. -----------------
\begin{speculation} Anyway, if this is correct and nVidia is going to be have official support for Linux they are probably going to use SGI sample implementation and thus cannot release their driver as open source. \end{speculation}
The EV6 bus used by Ahtlon and Alpha CPU:s is probably much better for SMP than Intel's bus. To begin with, the EV6 bus is clocked at 200 MHz whereas the Intel bus is clocked at 100 MHz.
The EV6 bus is also a point to point architecture, not really a bus in fact. The drawback is that the motherboard is more difficult to design.
nVidia's cards might be better for games, but SGI are certainly not targetting the games market... Fill rate is not everything. High end cards has most of the OpenGL pipe on the card.. as far as I can tell from the TNT GLX driver, the TNT only accelerates triangle setup.
Re:I can't run under RH 6.0, could run under RH5.2
on
Linux Q3Test 1.07
·
· Score: 1
Have you loaded the 3dfx module? If so, is the permissions on/dev/3dfx ok? (Be warned, a malicious user could crash the machine by poking into it)
Glide will fall back to mmap of/dev/mem for control of the 3dfx card if it can't use/dev/3dfx
Slashdot Mirror
Gareth did quite a lot as well. Most importantly, he started to write the driver...
A quick search at yahoo revealed a couple of Dungeons and Dragons fansites. At least one of them had a link to this site which should be interesting to you. It has the script of the last episode that was never produced:f ace.html
:)
http://www.mindspring.com/~michaelreaves/D&Dpre
And btw, If I was a moderator I would moderate you down to (Score:-5 Spoiler...)
I would be very surprised indeed if SGI released their sample implementatioin of OpenGL under a free license.
Well, if something falls into the event horizon the hole will grow.
But so will anything else if something hits them. The earth for example is constantly bombarded with particles from space.
Consider a star with the mass m and radius r.
Then consider a black hole with the same mass.
At the distance r from the center of that black
hole you would feel exactly the same gravitational pull from the black hole as you would feel from the star if you were standing on its surface.
The difference is that the gravitational pull of the black hole keeps increasing if your distance is less than r. This is in contrast to the gravitational pull of the star if you are inside it. (Since you have lots of mass around you pulling at you you can no longer simplify the star as a point formed gravitational source.)
So, you would actually have a harder time getting a black hole to grow as opposed to getting a star to grow since objects can pass closer to the black hole without crashing into them.
(Allright, some inaccuracies in this post, a star does not have a surface you can stand on, and it also loses mass by emitting energy, etc, but that isn't the point of the post)
I used a Solaris port of IE at one time and I was not terribly impressed. I don't think they would do a better job with the Linux port than with the solaris port.
Now, if Matrox would only release the warp specifications so that we could make secure direct rendering without a performance hit.
Some background:
The G200 and G400 has the ability to read and write to buffers in primary memory. This is a great feature, but if misused you can easily crash your computer or with a little more work do things like read and write kernel memory. Therefore we only allow root to do direct rendering in Utah GLX.
Thanks to Matrox' donation of the warp microcode we can now send a list of vertices to the card instead of having to manually calculating things like delta x and delta y values. (This is usually called triangle setup.) This was a great performance boast and also a key to more security since you cannot embed register writes in such a list of vertices.
Still, every time you want to change the current texture or change your current blending mode you will need to write to a register. And since the G200/G400 doesn't distinguish between a register write to change your blending mode and a register write that initiates a blit that will zero out the first 6 MB of framebuffer memory you a normal user cannot be allowed to write such data directly to the card. [1]
You can work around this by sending a buffer with some sort of bytecode to the kernel and let it do some sanity checks on it before sending it to the card. Thankfully the vertex lists cannot contain hidden register writes. [2].
This does not come without a performance penalty though.
What we could do if we had warp specifications is to write microcode that would take a buffer that not only contained vertex data but also information about all mode changes that was safe. Stuff like buffer allocation would still have to be done by the kernel or the X server, but you wouldn't have to do that very often.
I am not totally unreasonable, even though I would love to write some microcode myself I would be satisfied if Matrox provided microcode with this kind of functionality.
Still, this is a problem that will probably disappear in a couple of graphics card generations once multiuser systems is more common.
[1] Actually, the data isn't written directly to the card in any case if you are using DMA to transfer the commands from the host to the card. This is a key to high performance graphics in combination with the G200/G400.
[2] You can upset the card by writing improper values to the vertex list with the current microcode, you shouldn't be able to do more than a DOS attack with it though. The kernel or X server could probably detect this and restore the state of the card if this is tried as well. (I don't know if this is possible, but I think this is the case.)
Hey, we could trace radioactive material in our nature after that disaster... it is certainly a problem for more than just Ukraina...
The problem is that the Utah GLX module isn't compatible with Mesa 3.3 as yet.
If you checkout Mesa 3.2 it should work. Details for how to do that are in the FAQ.
The GLX configure script will print a big and ugly warning message if it finds Mesa 3.3 in the latest version.
Actually, I think it would be much easier to program a minimal interpreter in assembler.
Most programmers would have scant problems coding an interpreter from scratch. A compiler however is a different beast, and you wouldn't want to do that in assembler if you could avoid it...
Anyway, I think the first compiler was one of the most important computer related hacks of all time.
I couldn't get OpenGL to work with the files included with the demo. All I could get was a segment violation.
and besides, the Xig server is probably based on the same source base as XFree86. (The source code from MIT)
The GLX driver was written by David Schmenk of nVidia.
Doing a search for geforce on www.linuxgames.com revealed this snippet from an irc log:
-----------
([Jar]2) (orlock) WIll they still be supporting Xfree86/Mesa3D/glx/linux/etc like they have in the past?
(nvdaNick) Yes.
(MicroDooD) (LaRz17) Will drivers for multiple operating systems be released at the same time?
(nvdaNick) As for driver releases, I think NVIDIA is planning to release all drivers at once.
([Jar]) (MfA) Will the non windows drivers be open source? (ie not run through the pre-processor)
(nvdaNick) What would you want with open source drivers, by the way?
(nvdaNick) I'm not sure what our plans will be regarding that.
-----------------
\begin{speculation}
Anyway, if this is correct and nVidia is going to be have official support for Linux they are probably going to use SGI sample implementation and thus cannot release their driver as open source.
\end{speculation}
Interesting idea, but you can probably get more performance out of the GPU the closer it is to the graphics chip.
Still, this does exist in some form right now. Think 3dnow, AltiVec, etc. (Although this has much wider usage than just geometry processing)
Perhaps Direct3D isn't very good, but mister A. Coward didn't comment on Direct3D, but DirectX in general.
*feeding the troll*
Mozilla is one huge piece of application.
True, it is divided into smaller modules, but my impression is that the modules are still pretty big.
However, in a kernel some parts of the code is pretty small. Device drivers for example.
On the other hand, I'm not very positive about the SCSL, but it is much better than nothing at all.
irqs are archaic?
The EV6 bus used by Ahtlon and Alpha CPU:s is probably much better for SMP than Intel's bus.
To begin with, the EV6 bus is clocked at 200 MHz whereas the Intel bus is clocked at 100 MHz.
The EV6 bus is also a point to point architecture, not really a bus in fact. The drawback is that the motherboard is more difficult to design.
Only if the admin left security-mode=none
I think the G200 GLX module is somewhat working on the Alpha, check the g200-dev list for more info...
nVidia's cards might be better for games, but SGI are certainly not targetting the games market...
Fill rate is not everything. High end cards has most of the OpenGL pipe on the card.. as far as I can tell from the TNT GLX driver, the TNT only accelerates triangle setup.
Have you loaded the 3dfx module? If so, is the permissions on /dev/3dfx ok? (Be warned, a malicious user could crash the machine by poking into it)
/dev/mem for control of the 3dfx card if it can't use /dev/3dfx
Glide will fall back to mmap of
/AE
Leo Schwab of Be wrote an interesting editorial about shrinkwrap licenses:
http://www.microtimes.com/157/shrinkwrap.html
(It is a bit old, but good nonetheless)
In fact, before I got a harddrive for my 1200 I was regularly using a RAD disk. (RAD: is a device in AmigaOS that survives a reboot. Very nifty)
/Andreas