Re: [Fractint] system specs
. Phil, I don't know if this will help you, but here it is: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+, MMX, 3DNow (2 CPUs), ~2.4GHz x86 Family 15 Model 75 Stepping 2 AMDA64X246AM265W Memory: DDR2 2048 Meg, 803.6 MHz Phoenix - Award WorkstationBIOS v6.00PG Alienware MoBo: MB-FCNFORCE590SLI Graphics: NVIDIA GeForce 8600 GTS, 256 Meg RAM Windows XP Professional (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.050301-1519) DirectX 9.0c (4.09.0000.0904) It is over a year old, and it wasn't the highest high-end even when I bought it. But she sure cruises! You can see it here: http://www.fractal-animation.net/machinez.html For Dave's comment, yes - the G-card seems to be the main issue. I have upgraded my P3-733 / Win98SE system twice over the years; each new card performed worse with fractint (but better with games). The most recent was unusable in a win shell. The default image would draw but using any keys caused a lock-up. I finally put back in the original Hercules card (1999) and now fractint is cool again, but games suck. This is also the case with WinXP and current systems. There seems to be no rhyme or reason to it, at least that I can see. Some graphics cards work, some don't. Luck of the draw I guess. Cheers JoTz .
JackOfTradeZ@comcast.net wrote:
For Dave's comment, yes - the G-card seems to be the main issue. I have upgraded my P3-733 / Win98SE system twice over the years; each new card performed worse with fractint (but better with games). The most recent was unusable in a win shell. The default image would draw but using any keys caused a lock-up. I finally put back in the original Hercules card (1999) and now fractint is cool again, but games suck.
This is also the case with WinXP and current systems. There seems to be no rhyme or reason to it, at least that I can see. Some graphics cards work, some don't. Luck of the draw I guess.
Luck of the Windows device driver draw, I think. When the same hardware under OS/2 ran DOS Fractint just fine, and W98 could not, it's clearly device driver. (Well, also, the true machine separation that OS/2 provided vs the imitation that W98 never provided.) But my favorite video card for Fractint was a Hercules graphics card. ;-) -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <48E1B535.7060202@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
But my favorite video card for Fractint was a Hercules graphics card. ;-)
...only because fractint never tried to use your graphics card as anything other than a dumb frame buffer. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Richard wrote:
In article <48E1B535.7060202@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
But my favorite video card for Fractint was a Hercules graphics card. ;-)
...only because fractint never tried to use your graphics card as anything other than a dumb frame buffer.
Which was all it needed to be under DOS. I used to use an IBM PS/2 at work long ago. I don't know what graphics device it had inside, but Fractint could run it at 1600x1200x256 and a refresh rate of 110Hz. Far more than Windows could get out of the same hardware! -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <48E32CB2.8050107@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Richard wrote:
In article <48E1B535.7060202@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
But my favorite video card for Fractint was a Hercules graphics card. ;-)
...only because fractint never tried to use your graphics card as anything other than a dumb frame buffer.
Which was all it needed to be under DOS.
Sure, but graphics cards have moved way beyond that now. What fractint does with your video card now is purely a legacy compatability codepath that is the slowest way to use a modern video card, where "modern" is anything from the past 10 years. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Richard wrote:
In article <48E32CB2.8050107@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Richard wrote:
In article <48E1B535.7060202@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
But my favorite video card for Fractint was a Hercules graphics card. ;-) ...only because fractint never tried to use your graphics card as anything other than a dumb frame buffer. Which was all it needed to be under DOS.
Sure, but graphics cards have moved way beyond that now. What fractint does with your video card now is purely a legacy compatability codepath that is the slowest way to use a modern video card, where "modern" is anything from the past 10 years.
Might be true of the DOS version. XFractint is using my much more modern graphics cards through the X video system, so I doubt that it's using any legacy compatibility codepath ... I bet Fractint spends much more of its time calculating numbers than it does accessing the video card, anyway. I can't imagine how Fractint could possibly use many of the "newer" features (3D acceleration and game-oriented stuff). Perhaps it could offload processing code to a modern GPU? -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <48E48C7B.8020007@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Might be true of the DOS version. XFractint is using my much more modern graphics cards through the X video system, so I doubt that it's using any legacy compatibility codepath ...
True, but its still not using the card any smarter than treating it as a dumb frame buffer.
I bet Fractint spends much more of its time calculating numbers than it does accessing the video card, anyway.
True, but DOS fractint is *also* using the slow compatability path on the CPU.
I can't imagine how Fractint could possibly use many of the "newer" features (3D acceleration and game-oriented stuff). Perhaps it could offload processing code to a modern GPU?
There are lots of things fractint could do with the features of a modern video card. Some fractal computation can be GPU based making the computation scream orders of magnitude faster than what fractint can do now. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Richard wrote:
In article <48E48C7B.8020007@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Might be true of the DOS version. XFractint is using my much more modern graphics cards through the X video system, so I doubt that it's using any legacy compatibility codepath ...
True, but its still not using the card any smarter than treating it as a dumb frame buffer.
Actually, I think it is. Unlock dear old DOS Fractint, it happily renders in a graphical window on my Linux desktop - so it is clearly NOT using the card as a "dumb frame buffer". It's rendering graphics to an image window managed by the X video system, which is just another chunk of system memory.
I bet Fractint spends much more of its time calculating numbers than it does accessing the video card, anyway.
True, but DOS fractint is *also* using the slow compatability path on the CPU.
True. It still calculates far more numbers than it makes video accesses.
I can't imagine how Fractint could possibly use many of the "newer" features (3D acceleration and game-oriented stuff). Perhaps it could offload processing code to a modern GPU?
There are lots of things fractint could do with the features of a modern video card. Some fractal computation can be GPU based making the computation scream orders of magnitude faster than what fractint can do now.
Very true! Someone just needs to factor Fractint into two parts - a back-end processing engine (platform independent, compile and run on any hardware including a GPU, the supercomputer down the street or a render farm of commodity PC hardware) and a standard, documented API for accessing the processing engine. (Including over the network, hurrah for the built-in networking friendliness of X Windows!). And, of course, recode Fractint to support 32-bit color (RGBA) for some really neat transparency renderings .. Then someone could write a Javascript front end and we could have Web Fractint! ;-) -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <48E5E022.8000709@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Actually, I think it is. Unlock dear old DOS Fractint, it happily renders in a graphical window on my Linux desktop - [...]
Umm... if you're running DOS fractint in a window on your desktop, that has nothing to do with how fractint is treating your system, it has to do with how you're emulating DOS in a window on linux. Inside the DOS code it doesn't do anything fancier than treat the graphics card as a dumb frame buffer with support for colormaps and color cycling (which is just manipulating the CLUT). It isn't using any part of the graphics pipeline available in modern cards other than the frame buffer. The vast majority of the circuitry on your graphics card is idle when driven by fractint.
using the card as a "dumb frame buffer". It's rendering graphics to an image window managed by the X video system, which is just another chunk of system memory.
...which is still just a dumb frame buffer approach. Even xfractint doesn't use windowing in any way other than a dumb frame buffer. If you look at the code you'll find that all the access is dumb frame buffer style and the code goes through contortions to get that to work with the X window system in a window.
True, but DOS fractint is *also* using the slow compatability path on the CPU.
True. It still calculates far more numbers than it makes video accesses.
DOS fractint is using the 16-bit instructions. It is not using 32-bit math instructions, nor is it using SSE, SSE2, or even MMX/MMX2 instructions to accelerate things. I think somewhere there is a chunk of Pentium assembly code for the inner loop of the M-set, but that's probably about it. In xfractint, its compiled on gcc so you'd be getting 32-bit integer math instructions, although lots of the code assumes "int" is 16-bits and "long" is 32-bits, so the algorithms don't necessarily take advantage of the 32-bitness of gcc.
Very true! Someone just needs to factor Fractint into two parts - a back-end processing engine (platform independent, compile and run on any hardware including a GPU, the supercomputer down the street or a render farm of commodity PC hardware) and a standard, documented API for accessing the processing engine.
Its more complicated than that; the code is a mess. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
participants (3)
-
david -
JackOfTradeZ＠comcast.net -
Richard