Capabilities are good, but I prefer the Quality-of-Service ideas implemented in nemesis. This is an even more radical OS - it does away completely with traditional OS concepts like virtual memory and priorities. The result is an OS that can perform tasks like multimedia with blistering performance. A prerelease version is available for downloading here. It has a BSD style license.
This could easily be 10 dumb things linux users do:
1) Forgetting to check the Hardware-Compatibility HOWTO 2) Wrongly partitioning the hard disk 3) Using UMS-DOS 4) Forgetting to create a boot disk and not installing LILO 5) Creating a 1MB swap file 6) Micsonfiguring the network 7) Forgetting the root password (or setting it to root!) 8) Using libc5 applications 9) Applying kernel patches unwisely 10) Using different Linux distros on different machines
Perhaps NT and Linux aren't that different after all!
What I'd like to see is an end to installers entirely. Most PCs have bootable CD-ROM drives these days and could load games direct from CD `a la Playstation. Game data could be stored on floppy disks and no hard disk space would be required.
Linux would onbiously make the perfect choice for booting on the CD-ROM. A small kernel which autodetects the graphics, CD-ROM and sound hardware could be provided (as in Corel Linux) and that would be all.
I don't see why CSG isn't suitable for landscapes and racetracks. If you have a 'plane' primitive, you can use that as a base and just build on top of it using AND operations.
In my original post, I should have distinguished between CSG and raytracing. It is perfectly possible to raytrace a polygon model if CSG is too cumbersome.
Apologies for replying to my own post (bad form), but I hit 'Submit' too soon!
Regarding the 3dnow source code. It was written for a K6-2 300Mhz machine that I no longer have. I have only compiled it with gcc (requires a recent version of binutils for the 3dnow part) under Linux. It doesn't currently do CSG either, only a fixed scene containing spheres. Unfortunately the 3dnow part doesn't actually give any speed improvement at the moment! I suspect that the femms overhead is too big - suggestions welcomed. I'd be interested to see how this runs on an Athlon.
> http://www.art-render.com/products/rdrive.html A snip at $20,000!
Incidentally, 3dNOW and SSI are entirely suitable for raytracing. Since they were released I've had the dream of writing a realtime raytracer.
\begin{shameless plug} If anyone is interested, my first (suboptimal) attempt at producing a 3dnow raytracer is available at: ftp://ftp.dcs.ed.ac.uk/pub/cdw/ray/3dray.tar.gz Unfortunately I can't do any more until I get an AMD or P3 box. Feel free to copy/modify this code. Just let me know of anything you do. \end{shameless plug}
You are of course correct. You can render a CSG model and you can raytrace a polygon model. However, CSG is IMO the easiest model for raytracing, as polygons are for rendering.
/begin{rant} Constructive Solid Geometry (as used in POV etc.) is also an alternative to polygon-based rendering.
For those that don't know about it, with CSG the scene is built up from primitive blocks (e.g. cones, spheres, cubes, rods, etc). More complex objects are made by using boolean operations (AND, OR and DIFF) on the primitives. For example, a ring can be made by subtracting (DIFF) a rod from the centre of a sphere. Solid textures can be applied to the resulting objects, and raytracing can be used to produce shadows, reflections, transparency, etc.
Unfortunately, CSG and raytracing seem to have been overlooked by the graphics card manufacturers. The new effects proposed by 3dfx (motion blur, soft shadows, etc.) can be achieved very simply using stochastic raytracing. Raytracing has a reputation for being very processing-intensive, but I am convinced that it could be done efficiently in hardware, and the quality of the graphics would be far greater than polygon rendering.
In relation to the article - the Psi technique looks interesting, but seems to have very limited scope for application. IMHO, graphics card manufacturers should look at raytracing and CSG instead. /end{rant}
Unfortunately this article is rather short on details. What I would like to know is how AMD intend to extend the x86 intruction set into 64-bits. I really hope they don't just tweak the old CISC x86 instruction set with new addressing mode or something like that. It would be much better for them to design a new 64-bit instruction set (or base it on the Alpha). They could do this while still maintaining compatibility as follows:
The modern generation of x86 processors all use a 32-bit RISC-like core with a hardware translation from 32-bit x86 CISC. AMD could design a 64-bit RISC core and a hardware translation from 32-bit x86 CISC to 64-bit RISC. They could then allow programmers to bypass the translation and program directly for the RISC core, while still allowing x86 code to be executed.
Actually, I strongly suspect that this IS the way that AMD will go. The old NexGen CPUs (which AMD bought) allowed programs to be written directly for the RISC core bypassing the x86 translation step. However, I don't think any programs were ever written to take advantage of this.
If only they had released Xanadu as Open Source in the 80s, rather than waiting a whole decade. If they had, we'd probably be surfing the web using bidirectional links, infinite namespace and all the other cool things that Xanadu has. However, now that HTML has such a hold it is doubtful that Xanadu can ever make much of an impact.
Slashdot Mirror
Capabilities are good, but I prefer the Quality-of-Service ideas implemented in nemesis. This is an even more radical OS - it does away completely with traditional OS concepts like virtual memory and priorities. The result is an OS that can perform tasks like multimedia with blistering performance. A prerelease version is available for downloading here. It has a BSD style license.
This could easily be 10 dumb things linux users do:
1) Forgetting to check the Hardware-Compatibility HOWTO
2) Wrongly partitioning the hard disk
3) Using UMS-DOS
4) Forgetting to create a boot disk and not installing LILO
5) Creating a 1MB swap file
6) Micsonfiguring the network
7) Forgetting the root password (or setting it to root!)
8) Using libc5 applications
9) Applying kernel patches unwisely
10) Using different Linux distros on different machines
Perhaps NT and Linux aren't that different after all!
What I'd like to see is an end to installers entirely. Most PCs have bootable CD-ROM drives these days and could load games direct from CD `a la Playstation. Game data could be stored on floppy disks and no hard disk space would be required.
Linux would onbiously make the perfect choice for booting on the CD-ROM. A small kernel which autodetects the graphics, CD-ROM and sound hardware could be provided (as in Corel Linux) and that would be all.
Anyone else think it's a good idea?
I don't see why CSG isn't suitable for landscapes and racetracks.
If you have a 'plane' primitive, you can use that as a base and just build on top of it using AND operations.
In my original post, I should have distinguished between CSG and raytracing. It is perfectly possible to raytrace a polygon model if CSG
is too cumbersome.
Apologies for replying to my own post (bad form), but I hit 'Submit' too soon!
Regarding the 3dnow source code. It was written for a K6-2 300Mhz machine that I no longer have.
I have only compiled it with gcc (requires a recent version of binutils for the 3dnow part)
under Linux. It doesn't currently do CSG either,
only a fixed scene containing spheres. Unfortunately the 3dnow part doesn't actually give any speed improvement at the moment! I suspect that the femms overhead is too big - suggestions welcomed. I'd be interested to see how this runs on an Athlon.
> http://www.art-render.com/products/rdrive.html
A snip at $20,000!
Incidentally, 3dNOW and SSI are entirely suitable for raytracing. Since they were released I've had the dream of writing a realtime raytracer.
\begin{shameless plug}
If anyone is interested, my first (suboptimal) attempt at producing a 3dnow raytracer is available at:
ftp://ftp.dcs.ed.ac.uk/pub/cdw/ray/3dray.tar.gz
Unfortunately I can't do any more until I get an
AMD or P3 box. Feel free to copy/modify this code. Just let me know of anything you do.
\end{shameless plug}
You are of course correct. You can render a CSG model and you can raytrace a polygon model.
However, CSG is IMO the easiest model for raytracing, as polygons are for rendering.
/begin{rant}
Constructive Solid Geometry (as used in POV etc.) is also an alternative to polygon-based rendering.
For those that don't know about it, with CSG the scene is built up from primitive blocks (e.g. cones, spheres, cubes, rods, etc). More complex objects are made by using boolean operations (AND, OR and DIFF) on the primitives. For example, a ring can be made by subtracting (DIFF) a rod from the centre of a sphere. Solid textures can be applied to the resulting objects, and raytracing can be used to produce shadows, reflections, transparency, etc.
Unfortunately, CSG and raytracing seem to have been overlooked by the graphics card manufacturers. The new effects proposed by 3dfx (motion blur, soft shadows, etc.) can be achieved very simply using stochastic raytracing. Raytracing has a reputation for being very processing-intensive, but I am convinced that it could be done efficiently in hardware, and the quality of the graphics would be far greater than polygon rendering.
In relation to the article - the Psi technique looks interesting, but seems to have very limited scope for application. IMHO, graphics card manufacturers should look at raytracing and CSG instead.
/end{rant}
Unfortunately this article is rather short on details. What I would like to know is how
AMD intend to extend the x86 intruction set
into 64-bits. I really hope they don't
just tweak the old CISC x86 instruction set with new addressing mode or something like that.
It would be much better for them to design a new 64-bit instruction set (or base it on the Alpha).
They could do this while still maintaining compatibility as follows:
The modern generation of x86 processors
all use a 32-bit RISC-like core with a hardware
translation from 32-bit x86 CISC.
AMD could
design a 64-bit RISC core and a hardware translation from 32-bit x86 CISC to 64-bit RISC.
They could then allow programmers to
bypass the translation and program directly for the RISC core, while still allowing x86 code to be executed.
Actually, I strongly suspect that this IS the way that AMD will go. The old NexGen CPUs (which AMD bought) allowed programs to be written directly for the RISC core bypassing the x86 translation step. However, I don't think any programs were ever written to take advantage of this.
Why doesn't someone bootstrap a perl compiler written in perl? This is usually the way it is done?
If only they had released Xanadu as Open Source
in the 80s, rather than waiting a whole decade.
If they had, we'd probably be surfing the web using bidirectional links, infinite namespace and all the other cool things that Xanadu has.
However, now that HTML has such a hold it is doubtful that Xanadu can ever make much of an impact.