I never meant to imply that you don't need faster than X1800Xl .radeonic2 said:3dmark
Ya that's great and all, but how bout you play some real games at 1600x1200 with 4x fsas and 16AF and tell us that we dont need anything faster than a 1800xl.
Vista compliantTurtle 1 said:I never meant to imply that you don't need faster than X1800Xl .
I have a problem with screwing people over. Fact is I was going to quit building PC'S until after the Vista release.
When you sell someone a $5000 water cooled PC and its outdated in 1 year thats a bad thing .
So what i have done is I am selling vista compliant PC'S now. What the customer gets from me when Vista is released is a R600 already paid for . Hd or blu ray optic drive.(prepaid) ( I remove the X1800Xl'S and the Dual layer DVD's and replace with the new parts.)
I also advised all customers to buy the gate way 21" lcd or keep what they have all bought the gateway lcd. (Its Compliant)
They all got 2 gigs of memory.
The only thing I am unsure of is the harddrives. I told customers what I knew and the HD drives was a non-concern.
Yes the customers has to buy his own copy of vista. Since I lock the bios on these PC'S I will do the install free of charge.
Why do I lock the bios? These PC's come with 5 year warranty . Already O/C to there max . stable O/C . So to protect myself and the customers I lock the Bios. I sell to the 5 states around my own state only so its easy to take care of customers needs .
Right, but as I stated, the more you have in memory at once, the less work needs to be done.Mintmaster said:You're not thinking about this from a compiler's viewpoint and the dependency tree. You don't need to have the whole function you're integrating in memory at once.
In this case, of course, the instructions break up very nicely, and if you're smart about it, you don't need to use any more instructions with fewer registers. But, as you stated, you still need to do more work: more memory accesses.So if you're load limited, computation time scales as 1/(1 + 1/n), where 2+1.25n is the number of registers used.
Turtle 1 said:Wiel the dust issue bothered me cause of the time invoved. It's in the customers contract that I have to clean there PC's 1 a year.(5 years)
I am presently working on a PC case that has a Air cleaner installed in the lower part of the case with the PSU. This is the same type used in submarines. The only other fans will exhaust the clean cool air threw the RAD.
Hopefully I will have the case completed and ready for manufactoring . By Jan. 2006.
Yes I seen that problem coming . So what I did was Stoped using My watercooling system and case and switched to the Koolance PC3 725 BLorSL. Thats an expos2 in a Lian LI V1000 case. I have no fear of this case starving for cool air. Also keep in mind the only fans in this case are the 2 120mm case fans 2 120 rad. fans and 1 fan on the power&cooling SLI PSU.{Sniping}Waste said:Not a good idea. If you clean there systems 3 time a year then it will work but less then that then the dust will cloge the air filter and there goes the air flow through the case and overheating will start.
method: integrate(f,a,x,b)
given f, a, x, b (x=a+b/2, received as parameter)
if(abs(simpson-trap) < epsilon))
return simpson
else
return integrate(f, a, x/2, x) + integrate(f, x, x+b/2, b)
I don't quite see how, not without doing lots of recalculation. Specifically, if you make it tail recursive, you will have to recalculate f(b) about half of the time that it shows up, which would be (very, very roughly) a 50% increase in the amount of computation required (assuming the simpson and trap functions have computations times trivial in length compared to evaluating the function itself). Actual performance will, of course, depend upon the integral being evaluated.DemoCoder said:This is tree recursive, not tail recursive, but only reason this method isn't tail recursive is because of the first call to integrate (the plus would be taken care of by passing in an accumulator argument). I think with a little more thought, this method could probably be transformed into a tail recursive method, and then the extra stack space wouldn't be needed.
Well it is now that you've changed your numbers. 61% is different from 100%. The only conclusion I could make is that you said 100% because of architectural improvements.DemoCoder said:That was a typo. The context of my message is clear
I'm not sure if anyone said it would be a blowout, and I certainly didn't. One time I said "I think R580 would beat a 32-pipe 90nm G7x", and another time I said this hypothetical chip couldn't come close to R580 specifically in games with math-heavy shaders, like FEAR (where the X1600XT beats the GS quite substantially when bugfixed). It's going to depend a lot on the game/benchmark.Thus, I don't think an R580 and a 32-pipe G7x clocked similarly will be a blowout, especially since it depends on very heavy ALU workload.
Mintmaster said:Well it is now that you've changed your numbers. 61% is different from 100%. The only conclusion I could make is that you said 100% because of architectural improvements.
I'm not sure if anyone said it would be a blowout, and I certainly didn't. One time I said "I think R580 would beat a 32-pipe 90nm G7x", and another time I said this hypothetical chip couldn't come close to R580 specifically in games with math-heavy shaders, like FEAR (where the X1600XT beats the GS quite substantially when bugfixed). It's going to depend a lot on the game/benchmark.
Bill said:I hesitate to even post this but:
http://www.nextl3vel.org/board/index.php?showtopic=729
I thought R580 was 48 pipes?
And he's saying R520 is really 32? Would explain the large die size, but dont we have an X-Ray of the die? What does it show? How many qauds?
X-rays ! roflgeo said:When I hit my fourth in two paragraphs, I just gave up.
It's out, we have a die shot (something we never got with G70, btw), and still IT WILL NOT DIE. M'gawd.
I know, that was basically the whole point of my response to Chalnoth. The task had redundant data loading. My point is that a large quantity of these subexpression is nearly impossible to find in a realtime pixel shader.DemoCoder said:Extra registers are useful for time-space tradeoff if you want to eliminate common subexpressions. If you don't use the extra registers, you just have to recompute some values that get written over.
My point exactly. You can't output more than 16 values, so it's extremely rare to find use for so many registers.If you look at Forth programs for example, the stack for any given method never gets more than a few elements deep, especially methods that leave only one value as a result.
So why are you telling me that PS3.0 is so great without dynamic branching? That's where this whole thing started from. PS2.0 has 12 or 16 registers, which is plenty.The challenge is to find a balance. For the NV30, the limitation of 2 FP32 registers of 4FP16 registers (with huge penalty for exceeding) was too much, and aggressive non-cse would be needed, but you are then burning extra cycles. But once you get around 8 registers, you won't need many more except in pathological cases.
Well, I guess I'm not sure and I'm just making assumptions. There are a few games here and there where the X1800XT can significantly beat the 7800GTX, but only a few where the X1600XT beats the 6800GS. I do know that at Digit-Life, there are some shaders where the X1600XT is very nearly 3 times the speed of the X1300Pro, so I know such circumstances do exist.DemoCoder said:Are you sure that FEAR shaders are as math heavy as you think they are? Has anyone ripped out any of the shaders and calculated math:texture instruction ratios?
Well, first of all, people have been reporting ~35% increase in that thread on these boards. Secondly, that driverheaven review only updated the 2xAA score, which has always had a higher hit on ATI cards than on NVidia. The framerate went from 23fps to 34fps: a 50% increase. If you add a conservative 30-40% to the noAA and 4xAA scores, it'll be way ahead of the 6800GS.Also, what benchmarks are you looking at? DrivenHeaven for example has *fixed* FEAR benchmarks at http://www.driverheaven.net/reviews/X16_GS/fear.htm that don't show any substantial beatdown against the GS.
Mintmaster said:So why are you telling me that PS3.0 is so great without dynamic branching? That's where this whole thing started from. PS2.0 has 12 or 16 registers, which is plenty.
Looking now at this discussion between you and Chalnoth, I see you brought recursion up as an example, but that's about as branching heavy as you can get.
It's well outside the context of my statements, because my claim is this: PS3.0 without dynamic branching offers almost nothing over PS2.0+ (i.e. ps_2_x).
(PS2.0+ does offer something over PS2.0, but just a tad, and NV3x was deficient in so many other areas that it couldn't take advantage of them. That's getting a bit off topic, though...)