[Mr.E]

Originally posted by Gee-Man:
<STRONG>

Please, stop repeating this stuff when you don't know the technical details involved! It is NOT obvious that slow cards like the Rage 128 can handle Quartz Extreme, the current usage of the video card IS NOT THE SAME AS QUARTZ EXTREME. Either way, please stick to one argument - either the older cards CAN handle QE, and Apple is simply trying to sell hardware (not true, but that's your argument), OR the hardware CAN'T handle it, and Apple needs to provide options to "turn off effects" to compensate. You can't have it both ways, you know.</STRONG>

I never said it could handle Quartz Extreme. However, the video card is given tasks to do now (such as moving around window contents), and is inert most of the time in 10.1. I think regular Quartz could see plenty of acceleration via the hardware without the use of Quartz Extreme.

[Mr.E]

Originally posted by Gee-Man:
<STRONG>

But don't fool yourself about the work involved. One example "simple checkbox" solution is available RIGHT NOW - if you download "Shadow Killer" from Unsanity, it eliminates one of the biggest drags on the CPU, the drop shadows. Running this program makes OS X windowing noticably faster, but it also makes things very hard to read given the design of OS X - windows don't have a border, so they tend to blend together too much. A checkbox built-in to OS X for this wouldn't solve the problem - they'd have to have a re-designed window appearance in order for this to work. All this is possible, but it will take real work, it's not simply a matter of an hour like you assume.</STRONG>

I believe Shadow Killer includes an option to limit window shadows to a couple pixels. Getting rid of the shadow altogether does make things ugly. Apple should provide this customization with THEIR software, and it really should not be the task of a third party vendor.

[Homer1946]

Originally posted by Mr.E:
<STRONG>

I believe Shadow Killer includes an option to limit window shadows to a couple pixels. Getting rid of the shadow altogether does make things ugly. Apple should provide this customization with THEIR software, and it really should not be the task of a third party vendor.</STRONG>

I like Aqua, and Quartz is the future, PC's will change to a composting diplay model soon enough. However, I would rather Apple spend its time finishing OS X to bring it into feature parity with OS 9 (like Printer Sharing), adding new features to take advantage of Unix, and even new technolgies like zeroconf, rather than adding more GUI options. There will be plenty of time for that when X is more finished, and 3rd parties until then.

[KellyHogan]

Originally posted by Homer1946:
<STRONG>

I like Aqua, and Quartz is the future, PC's will change to a composting diplay model soon enough.</STRONG>

It already does and was doing it for the past two years. A little bit in Windows 2000 and quite a lot with apps like Object Desktop.

Windows XP gives the options to fiddle with each and every effect turning them all off if you have a slower machine or using themes which are easy to process such as the Windows Classic theme. Microsoft don't make computers so it is easy to understand why they do this. They want to get XP running on many many different systems. Apple however make their money from selling hardware and if they don't get their niche market to upgrade then they will die.

[moki]

I swore I wouldn't do this, but I decided to write up some concrete examples of what we're talking about with texture tiling -- and keep in mind this doesn't include any of the Quartz Extreme architecture that I am NDA-bound not to.

Let's take a closer look at the "tiling" idea. For these purposes, we'll assume that we're working on a relatively small screen size -- 1280x1024 pixels in 32 bit color mode. Let's create a document window that is a standard size to fit this screen area -- let's go with 800x900 pixels in size.

The standard buffer size for this window is 800x900x4 (1 byte for each of the ARGB color components), or 2,880,000 bytes just for the backing store for that window. Let's consider that we have about 30 windows of this size open -- not an uncommon thing in Mac OS X by any means, especially with a few applications open. So for our window backing stores, we have 86,400,000 bytes (just giving everyone an idea of exactly how much RAM we're talking about here).

This is how much memory Quartz pushes around; this is the cost of a unified composited imaging model (which, by the way, is a very, very good thing -- it is quite forward-thinking). I think you'll see that having to juggle this amount of RAM puts a serious strain on your memory bandwidth. Now lets look at using textures to do this.

Since the Rage 128 is limited to power of 2 texture sizes, we have a choice of 2x2, 4x4, 8x8, 16x16, 32x32, 64x64, 128x128, 256x256, 512x512, 1024x1024, etc. for our texture maps. We could pick the biggest power of two texture that would cover this area, but in this case, it would result in 1024x1024x4 = 4,194,304 bytes for that texture. That's about 1.4mb of wasted VRAM -- clearly that's a good bit to waste, especially when you consider that our textures for our windows will now take up 125,829,100 bytes -- or about 39mb more VRAM then the actual buffer size.

We're talking about video cards with 32mb of VRAM, right? Yes, textures can be offloaded to main RAM -- but there is a speed penalty involved in doing this; your fast-access RAM is on the video card, and it takes time to load and unload textures. This isn't a zero-sum game, as you stuff more things into the video card's fast VRAM, other things must be offloaded to make room while those textures are being processed -- then the offloaded textures need to be swapped back into complete the composited screen image.

It might seem like a lazy way to do things -- using the largest texture size that will fit a window -- but there are reasons you might choose this over more granular tiling that will become clear (even though it wastes a huge amount of VRAM and will result in a lot of swapping and trips to main memory).

The other thing to keep in mind is that with this power of two limitation, we're looking at some serious problems if the window is resized in any direction to be larger than 1024x1024 -- we then need to jump up to a 2048x2048 texture, which is when we seriously start to waste memory. A single 2048x2048 texture takes up 16,777,220 bytes of RAM -- yes, 16mb for a single window -- multiple that by our 30 windows, and we're talking about 503,316,500 bytes for our 30 windows -- 500mb. Ouch. Clearly unworkable.

Let's say instead we want to try to be smart and divide the window up into a smaller set of tiles. Perhaps we'll pick a single fixed size that makes sense, to simplify things -- let's say our base texture tile size is 256x256. For our window, we'll need 4 of these textures in each direction, or 256x256x4x(4x4) = 4,194,304 bytes total for our 16 textures that cover the window completely. Hey, look at that -- we're using the same amount of RAM we used for our single texture -- but at least this way it'll scale a bit better when our window gets larger -- if we went to something larger than 1024 in one direction, we'd only be looking at 256x256x5x4x4 = 5,242,880 vs (best-case) 1025x1024x4 = 4,198,400 for a standard buffer.

However, we're shifting part of the burden -- the CPU need to preprocess the textures, divide them, and send them all to the video card individually, and they all must be rendered individually. We've gone from rendering a single texture to rendering 16 textures.

Oh, and what if we actually want to change the contents of our now sub-divided window (something that is extremely common for a GUI, but much less so for games). We'd have to build all sorts of complicated logic to calculate what drawing intersected what texture and have all of the calculations and drawing done by the video card -- and the Rage 128 is not a video card that is programmable to do fun things like this -- it does a strict set of specific things well, and that's all she wrote.

You could approach it one of two ways -- you could render the pixmap to be stamped in software, sub-divide it, and send each 16 parts of the pixmap to the video card separately (calculating the intersections -- and each intersected texture is power of 2-constrained, and thus takes up significantly memory than it needs to). Or you could send one pixmap (again, a power of 2, don't forget!) to the video card, and stamp it on each individual window tile texture (worst case, stamp it 16 times -- on top of the 16 times you'll render the final textures for the window once it is done).

Or, if the video card supported it, you could render everything entirely on the video card, sending it just the raw drawing commands (but you'd again have to render all of the drawing 16 times, once for each texture) -- however, guess what? The Rage 128 doesn't support the drawing that Quartz does, and it isn't programmable to do so. I don't think people would be happy that their nice Quartz antialiased text doesn't work anymore -- or a myriad of other features like clipping paths don't function like they should. Quartz can't be done in hardware on fixed video cards like the Rage 128.

So we're back to having to render our pixmaps in software, and sending 'em to the video card -- either in one big pixmap (rendered 16 times worst case, on top of the 16 times the finished window tile textures will need to be rendered), or we can sub-divide our texture and send along 16 individual textures and render them each once, then render each of the 16 changed window tile textures (worst-case again).

Remember, however, that these "changed area" textures are also power of 2 limited, and any time you shift the burden from the video card to render the textures to the CPU to calculate the sub-divisions, all you're doing is tying up the CPU. It already had to render the changed area, now it has to sub-divide it, calculating the intersections, and factor in the power of 2 considerations (and the extra memory the changed texture occupies) etc.

We *did* want to accelerate things, didn't we? Putting aside the rather massive amounts of wasted precious VRAM that a tile-based system would gobble up (which not only results in less stored in the fast VRAM, but also takes significantly more time to send over the bus), we're also making a non-trivial amount of preprocessing to do before such a system could render anything accurately.

This is a fairly linear problem that AltiVec wouldn't help much with in terms of accelerating, and we also want our system to work on non-AltiVec systems (you know, the ones that need the speed the most -- that old accelerating thing again). Certainly would could attempt to get even smarter and use more than one texture size per window, but remember this not only significantly adds to the preprocessing overhead, but also it also makes the preprocessing problem much more complex and CPU intensive. We're also looking at increasing the individual number of textures and renders -- it all adds up.

Let's say for our window we decide to render only 3 256x256 textures, we've got 800-768 = 32 pixels left horizontally (we got lucky, this is the best-case, a power of 2), and 900-768 = 132 pixels left to render vertically. If we took the simple case and stuck with the next-size down power of 2 texture (128x128) to render the remaining window bits, we end up with 7x1 128x128 textures to render the right side of the window and 8x2 128x128 textures to render the bottom bits, for a grand total of (3x3) + (7x1) + (8x2) = 32 textures to render. We just doubled the number of textures we need to calculate the intersection with and render.

Have fun calculating where the "changed area" texture intersects all of these rectangles, and rendering it either 32 (worst-case) separate times, or precalculating the intersection 32 times and uploading each changed texture area individually and rendering them each once (worst case -- on top of the 32 textures that will need to be rendered for the final tiled window textures). And we're still wasting a good chunk of precious VRAM as well as memory bandwidth shuttling these bits to and fro (and our changed area, remember, has to be a power of 2 as well).

If it seems like this is getting unwieldy, then gold star -- you're right, it is. On one end of the spectrum we waste gobs of VRAM to eliminate the preprocessing and iterative rendering bottlenecks, or on the other end of the spectrum we save VRAM by calculating a myriad of sub-divisions and upload, intersect, and render each one individually. VRAM on one side of this power of 2 dilemma, processing and rendering overhead on the other. The more you sub-divide things to not waste so much precious VRAM, the more you add pre-processing, uploading, and rendering overhead.

Even with AGP, the Rage 128 is not a video card that is optimized to handle this constant texture juggling -- games, after all, upload the majority of their textures at once so that the gamer doesn't see a performance hit just because a texture that isn't in VRAM is accessed.

This is a case where there is no sweet spot -- you either waste time and VRAM on one side with big textures, or you waste preprocessing, uploading, and rendering cycles. Oh wait, did I forget I was still only talking about one window? Let's apply this to our 30 windows -- we end up with 960 textures that must be rendered (worst-case) to complete the raster display vs. 32 textures if each window just had one texture associated with it. And we're still wasting significant chunks of bandwidth and VRAM.

Before anyone mentions it, texture compression isn't going to alleviate the bandwidth or CPU issues -- first, we're talking about a GUI; the lossy techniques that can be used in the Rage 128 in a game to really save VRAM need not apply. We also need to render our pixmap via the CPU (Quartz can't be rendered from the Rage 128 video card, remember?), which has to be done uncompressed, so we either compress the texture in via the CPU (wasting yet more precious CPU cycles we were purportedly trying to save) and send it along compressed, or we upload the textures raw and let the video card do the compression (and here we are wasting bandwidth sending the textures along).

Texture compression works well in video cards when the texture is compressed and sent along to the video card once, not when it is constantly being changed and re-compressed (either by the video card of by the CPU).

Certainly there are a few tricks you could use here and there to attempt to speed up this final window render, but the fundamental issues remain.

We did want to accelerate the drawing, didn't we? Not just use the video card to do some of the drawing because it sounds like a good idea?

[moki]

Originally posted by Mr.E:
<STRONG>

I never said it could handle Quartz Extreme. However, the video card is given tasks to do now (such as moving around window contents), and is inert most of the time in 10.1. I think regular Quartz could see plenty of acceleration via the hardware without the use of Quartz Extreme.</STRONG>

In a programmable, flexible video card that is meant to do more than a few limited things (and do them very well), yes. In the "old-style" Rage 128, no -- it just isn't able to do the things Quartz renders, not for the things that really need it (eg: Quartz-style text rendering).

[moki]

Originally posted by KellyHogan:
<STRONG>

G4 'super computer', hee hee.</STRONG>

As someone who has done a fair bit of AltiVec coding, I can tell you that you can indeed realize pretty amazing results by AltiVec-optimizing certain algorithms -- that might explain the popularity of G4s in the scientific community where custom algorithms are regularly coded by scientists.

[Gee-Man]

Originally posted by moki:
<STRONG>snip of a dead-on technical explanation...</STRONG>

Blammo - point proved. GREAT explanation, moki, I was trying to come up with something like this without breaking NDA myself, but you've just solved the problem rather nicely.

It's not marketing, it's not a conspiracy, it's REAL. Can we all just move on now?

[a holck]

Very nice explanation!

Finally some info from a person that knows what he is talking about (and not guessing)

[KellyHogan]

Originally posted by moki:
<STRONG>I swore I wouldn't do this, but I decided to write up some concrete examples of what we're talking about with texture tiling -- and keep in mind this doesn't include any of the Quartz Extreme architecture that I am NDA-bound not to.


</STRONG>

Good, Moki. Should have done that type of thing earlier. However, we are now back to two things. Radeon Mobility. How well supported would that be considering it is crippled compared to the desktop version? Second, if Apple starts usingn higher res TFT screens in one year or so then logically people will be using higher res windows. What then to owners of current 32MB cards built in to their iMacs and so on?

[ 05-13-2002: Message edited by: KellyHogan ]

[Guy Incognito]

Originally posted by a holck:
<STRONG>Very nice explanation!

Finally some info from a person that knows what he is talking about (and not guessing)</STRONG>

Does it matter? moki explained this to someone that currently has his fingers in his ears and shouting like a little kid 'LA LA LA LA LA! I'M NOT LISTENING!!! LA LA LA LA!'

Wanna bet that KellyHogan's gonna quote moki's huge explanation and simply have this to say: 'I have no doubt that the Rage 128 can handle Quartz Extreme.'

If everyone could make a collective effort to just ignore Mrs. Hogan (hehe) maybe she'll (re: hehe) just fade away silently.

I'm gonna start to ignore her (LOL) riiiight abouuut...NOW!

[a holck]

Originally posted by Guy Incognito:
<STRONG>

Does it matter? moki explained this to someone that currently has his fingers in his ears and shouting like a little kid 'LA LA LA LA LA! I'M NOT LISTENING!!! LA LA LA LA!'
</STRONG>

True

[KellyHogan]

Originally posted by Guy Incognito:
<STRONG>

Does it matter? moki explained this to someone that currently has his fingers in his ears and shouting like a little kid 'LA LA LA LA LA! I'M NOT LISTENING!!! LA LA LA LA!'

Wanna bet that KellyHogan's gonna quote moki's huge explanation and simply have this to say: 'I have no doubt that the Rage 128 can handle Quartz Extreme.'

If everyone could make a collective effort to just ignore Mrs. Hogan (hehe) maybe she'll (re: hehe) just fade away silently.

I'm gonna start to ignore her (LOL) riiiight abouuut...NOW!</STRONG>

I'm not a woman, everyone knows that and so do you, and I'm not a moron like yourself.

I have now asked:

Radeon Mobility. How well supported would that be considering it is crippled compared to the desktop version? Second, if Apple starts usingn higher res TFT screens in one year or so then logically people will be using higher res windows. What then to owners of current 32MB cards built in to their iMacs and so on?

[Frek]

There's something I just don't get here....
Why are everybody interested about QX on the ATI Rage 128,
The Rage 128 doesn't support all of the features of Quartz that's for sure, but that shouldn't prevent quartz to take adventage of the features it _does_ support, as line/edge antialiasing, filtering etc,
there's things that can be accelerated out of the scope of "Quartz-antialiased-text" on the Rage 128, transparency for example.
(And yes I really think apple should allow the user to "cripple" the eyecandy features unless he/she wants it)

Besides there's otherthings I find that apple should take alook at infront of quartz, as the Mach-O runtime system, I just made a few tests and all of them shows that mach-o is about 5-6 times slower a function call than the same PEF/CFM code.

[TC]

Kelly Hogan and Frek, can you just exchange addresses and discuss this privately? I see the start of a beautiful relationship.

Also, how is the screen resolution of an iMac with a built in screen going to change in the future?

[Frek]

Originally posted by TC:
<STRONG>Kelly Hogan and Frek, can you just exchange addresses and discuss this privately? I see the start of a beautiful relationship.
</STRONG>

Discuss this privately ?
I thought this thread was about Quartz Extreme on PCI graphics- No ?

[moki]

Originally posted by KellyHogan:
<STRONG>

Good, Moki. Should have done that type of thing earlier. </STRONG>

Out of curiosity... why should *I* have done that earlier? Why are you right about any demi-informed speculation you choose to put forth until someone has to sit down for an hour and make the points excruciatingly clear. Ugh.

I'm sure you're a fine person, Kelly, but you can't carry the "I'm right about my speculation until I'm proven wrong" mentality about this technical issue, about my motives for stating that the Rage 128 wasn't doable (an apology would be nice, btw), and so on.

*sigh*

[moki]

Originally posted by Frek:
<STRONG>There's something I just don't get here....
Why are everybody interested about QX on the ATI Rage 128,
The Rage 128 doesn't support all of the features of Quartz that's for sure, but that shouldn't prevent quartz to take adventage of the features it _does_ support, as line/edge antialiasing, filtering etc,
there's things that can be accelerated out of the scope of "Quartz-antialiased-text" on the Rage 128, transparency for example.</STRONG>

This isn't a solution that can be done piecemeal with the Quartz imaging model the the way you suggest. The main tenant of Quartz is that you have one shared memory imaging model -- more analogous to a video mixer than the traditional raster display technologies.

Let's say we have a window buffer we're drawing to. We want to draw a nice antialiased line in it (let's forget for the moment that Quartz uses an imaging model with the kind of precision that video cards don't support in hardware). We want to call the hardware function to draw this line... OK, we need to shuttle our entire pixmap buffer to the video card to draw that line in order for it to really benefit from the hardware acceleration.

Ooops, now we want to draw Quartz text in the buffer... we need to shuttle the entire buffer back to main memory to do that. Certainly this can be sped up by hardware DMA from the video card, but it still takes time to do the transfer.

All of this back and forth exchange of very large pixmaps (we need to retain coherency, remember) takes its toll, and isn't worth the acceleration you gain from the video card except for very expensive operations (such as bit blits).

This doesn't even touch on fundamental concepts in Quartz like clipping paths that aren't easily emulated by video cards, at least not with the same precision and algorithms that Quartz uses.

It isn't a simple issue -- Apple made a bold move with Quartz, and they are taking a lot of heat for it. However, I think they made the right choice by picking an imaging model that will scale *extremely* well over the coming decade.

[Frek]

Originally posted by moki:
<STRONG>
Let's say we have a window buffer we're drawing to. We want to draw a nice antialiased line in it (let's forget for the moment that Quartz uses an imaging model with the kind of precision that video cards don't support in hardware). We want to call the hardware function to draw this line... OK, we need to shuttle our entire pixmap buffer to the video card to draw that line in order for it to really benefit from the hardware acceleration.
Ooops, now we want to draw Quartz text in the buffer... we need to shuttle the entire buffer back to main memory to do that. Certainly this can be sped up by hardware DMA from the video card, but it still takes time to do the transfer.
</STRONG>

Yes indeed, but I thought more about a specific usage less than general (right now I can't think of any "cpu-hog" operation that invokes line antialiasing though, I just said that in my previous post to point out features the R128 supports rather than like everybody else pointing out what features it does not support), like "post-processed" additions, as for example the menu transulency, there's no reason to draw the text after the composite has been constructed.

<STRONG>
All of this back and forth exchange of very large pixmaps (we need to retain coherency, remember) takes its toll, and isn't worth the acceleration you gain from the video card except for very expensive operations (such as bit blits).
</STRONG>

I agree.

<STRONG>
This doesn't even touch on fundamental concepts in Quartz like clipping paths that aren't easily emulated by video cards, at least not with the same precision and algorithms that Quartz uses.
</STRONG>

I'm pretty sure the stencile buffer can be used to "simulate" clipping paths, no not the same algorithms but should have the same result.

<STRONG>
It isn't a simple issue -- Apple made a bold move with Quartz, and they are taking a lot of heat for it. However, I think they made the right choice by picking an imaging model that will scale *extremely* well over the coming decade.</STRONG>

I agree, but it makes you wonder why apple didn't adopt it abit more loosely, I think they could have concentrated on a more advanced graphics pipeline after they reviewed the rest of the OS, this doesn't really give any better experience in my opinion, the OS has a great potential but very few computers can live up to it as for now.

[ 05-13-2002: Message edited by: Frek ]

[squiggy]

Originally posted by moki:
<STRONG>
All of this back and forth exchange of very large pixmaps (we need to retain coherency, remember) takes its toll, and isn't worth the acceleration you gain from the video card except for very expensive operations (such as bit blits).

This doesn't even touch on fundamental concepts in Quartz like clipping paths that aren't easily emulated by video cards, at least not with the same precision and algorithms that Quartz uses.

It isn't a simple issue -- Apple made a bold move with Quartz, and they are taking a lot of heat for it. However, I think they made the right choice by picking an imaging model that will scale *extremely* well over the coming decade.</STRONG>

The main blockage for QE on PCI is bandwidth. Arshad (of ATI) said on the xlr8yourmac.com forums that it was tried and found to be too slow. The Rage 128 cards have the added disadvantage of the texture size limitations described by Moki. It sucks but we just have to deal with the fact that it can't be done.

That doesn't mean they couldn't have *any* better utilization of the video hardware on older systems. It should be possible to do hardware scrolling, currently it appears they still re-paint the entire scrolled region. I'm not sure how much of an advantage this would be due to the imaging model, but it'd at least save bus bandwidth.

In general I think people are expecting too much from QE - all it seems to be doing right now is offloading some of the compositing from the CPU (that is, of the windows themselves), the transitions (genie & friends), possibly the shadows, and probably better utilization of AGP. It's not doing some grand conversion to an OpenGL UI. I'm sure they'll take advantage of new technology in video cards down the line to accelerate more of the interface, but right now this is what is possible with the display model.

[a holck]

Originally posted by squiggy:
<STRONG>
In general I think people are expecting too much from QE - all it seems to be doing right now is offloading some of the compositing from the CPU (that is, of the windows themselves), the transitions (genie & friends), possibly the shadows, and probably better utilization of AGP.</STRONG>

According to a news sites, one of the Quarts Extreme demos at the keynote was a slow geenie minimization of a playing QuickTime window.
If this is true one would expect that the transition is infact done by the GFX card, but I can only guess as this is covered by NDA for all that do know.

[moki]

Originally posted by a holck:
<STRONG>

According to a news sites, one of the Quarts Extreme demos at the keynote was a slow geenie minimization of a playing QuickTime window.
If this is true one would expect that the transition is infact done by the GFX card, but I can only guess as this is covered by NDA for all that do know.</STRONG>

Anything shown at the keynote is supposedly is fair game to talk about -- and considering it was covered on video by the press, I think that's understandable.

Me -- I'm not risking it.

[ 05-13-2002: Message edited by: moki ]

[a holck]

Sorry, I was not clear enough.
I did not mean what happened during the keynote was under NDA.
But what was actually accelerated by the GFX board

[Big Mac]

Originally posted by KellyHogan:
<STRONG>

You should know how large my penis is, my son.</STRONG>

Hogan, everyone knew you were unabashedly ignorant and, moreover, a disgusting excuse for a human being in all respects. However, I'm wondering now whether you're actually one of those cardinals I hear about on the evening news. I value my excrement above your miserable life, Hogan. And if I saw you drowning, I'd throw you a brick.

[mbryda]

Originally posted by KellyHogan:
<STRONG>

Radeon Mobility. How well supported would that be considering it is crippled compared to the desktop version? Second, if Apple starts usingn higher res TFT screens in one year or so then logically people will be using higher res windows. What then to owners of current 32MB cards built in to their iMacs and so on?</STRONG>

Well, considering the new iMacs are capped at 1024x768, that's a moot point. (I think the older ones are too) If Apple puts a 1280x1024 or whatever in the iMac 3, they will bump the video card's RAM up to 68 or 128MB.

-Matt

[nickshanks]

Originally posted by moki:
<STRONG>

Anything shown at the keynote is supposedly is fair game to talk about -- and considering it was covered on video by the press, I think that's understandable.

Me -- I'm not risking it.

[ 05-13-2002: Message edited by: moki ]</STRONG>

Umm, you weren't there, right?
It was a DVD, not a QuickTime movie.
And it isn't under NDA.

[wadesworld]

Good, Moki. Should have done that type of thing earlier.

Do my eyes deceive me, or is that Kelly's way of saying "I was wrong. I had no idea what I was talking about. Now that moki has explained it to me, I realize that all my previous posts had no merit?"

Wade

[Nonsuch]

Originally posted by wadesworld:
<STRONG>

Do my eyes deceive me, or is that Kelly's way of saying "I was wrong. I had no idea what I was talking about. Now that moki has explained it to me, I realize that all my previous posts had no merit?"

Wade</STRONG>

Yes, but you'll notice it's still moki's fault.

[KellyHogan]

Originally posted by Big Mac:
<STRONG>

Hogan, everyone knew you were unabashedly ignorant and, moreover, a disgusting excuse for a human being in all respects. However, I'm wondering now whether you're actually one of those cardinals I hear about on the evening news. I value my excrement above your miserable life, Hogan. And if I saw you drowning, I'd throw you a brick. </STRONG>

And we all know you are an extremist who advocates throwing all Palestinians out of their homes.

[KellyHogan]

Moki, could you answer my questions regarding the Radeon Mobility and also the effect of even higher res screens in a years time on Macs which aren't exactly shipping with the latest graphics chips?

[Orbit]

ok, that crossed a line. do NOT bring israeli/palestinian politics into this board, i beg of you. jokingly or otherwise. thanks.

[Mac-arthur]

Originally posted by KellyHogan:
<STRONG>Moki, could you answer my questions regarding the Radeon Mobility and also the effect of even higher res screens in a years time on Macs which aren't exactly shipping with the latest graphics chips?</STRONG>

Why don't you cut the guy a break Kelly? He already bent over backwards to explain to you in excruciating detail why QE will not work on the Rage128. It seem you are asking Moki to predict the future now? That would cause him to break the Temporal NDA that Apple forces all Developer/Psychics to sign...


[ 05-14-2002: Message edited by: Mac-arthur ]

[Metzen]

Originally posted by KellyHogan:
<STRONG>I'm not a woman, everyone knows that and so do you, and I'm not a moron like yourself.
</STRONG>

Wasn't it you who just a few hours ago was insisting on making the Rage 128 work with Quartz Extreme a trivial task?

Haha! I love hypocrites! They are *WAY* too damn funny. So, Kelly Hogan, are you going to make Quartz Extreme work with the Rage 128 or not?

Originally posted by KellyHogan:
<STRONG>I have now asked:

Radeon Mobility. How well supported would that be considering it is crippled compared to the desktop version? Second, if Apple starts usingn higher res TFT screens in one year or so then logically people will be using higher res windows. What then to owners of current 32MB cards built in to their iMacs and so on?</STRONG>

How about instead you do some ****ing research instead of trying to get the answers you ignorantly don't want handed to you on a plate?

[Its_me]

Originally posted by KellyHogan:
<STRONG>

Second, if Apple starts usingn higher res TFT screens in one year or so then logically people will be using higher res windows. What then to owners of current 32MB cards built in to their iMacs and so on?</STRONG>

Huh? How are people with current iMacs going to use higher resolution screens? Its not like you can easily swap the screen.

In a year, if higher resolution LCDs are used in iMacs, they might ship it with more video RAM....do you think the iMacs will be stuck with 32MB video cards forever?

[a holck]

Well, only the Powermac G4 and the new PowerBook G4 have a Digital video connector, which is needed to drive a Flatpanel of high resolution.

- The Powerbook can drive external digital screens of max. 1920x1200.
Today's mobile chipsets can max. drive screens of 1920x1200 (including the Geforce4togo 440).

- The current Powermac G4 can drive external digital screens of max. 1920x1200, except the Geforce4Ti which can drive displays of 2048x1536. This is a limitation of the graphics chip.

The Imac2, the Ibook, and the old Powerbook only have analog vga connectors, so it would not be possible to connect a better digital display.

[a holck]

Also, the current aqua interface will not change in the foreseeable future. All the parts are pxm# maps. and are not scaled.
So if your fear is that Apple would make the interface parts even bigger, and force users to use higher resolutions, it won't happen unless they (and all devolopers) change a lot of things.

[moki]

Originally posted by KellyHogan:
<STRONG>Moki, could you answer my questions regarding the Radeon Mobility and also the effect of even higher res screens in a years time on Macs which aren't exactly shipping with the latest graphics chips?</STRONG>

I really can't go into the details except to say that conceptually, the best way to think of QE in its first incarnation is to think of it as a cache for frequently used GUI elements/windows. The windows/menus you're working with are always kept in the cache so they are responsive -- the more VRAM you have, the more stuff can be kept in fast VRAM.

The graphics cards that are shipping now are fast and flexible enough to handle the compositing -- the more VRAM you stuff in 'em the better.

[ 05-14-2002: Message edited by: moki ]

[edddeduck]

I would like to say cheers Moki for the explaination. Although I already knew it was not possible I learnt a few things about GF cards etc and it was the best post I have read on these forums in a long while.

From a Mac User in a PC flat I think 10.2 is great and OS X in general is becoming a great asset to apple. On of my flatmates might be buying a mac....

[OFFTOPIC] btw I have found a bug in my copy of EV Nova where do I mail it...) [OFFTOPIC]

Cheers Edwin

[moki]

Originally posted by edddeduck:
<STRONG>
[OFFTOPIC] btw I have found a bug in my copy of EV Nova where do I mail it...) [OFFTOPIC]
</STRONG>

[email protected]

We're coming out with 1.0.1 very soon, btw...

[Developer]

OK, I will take over Kelly's point of view for a second.

As far as I understand QE it speeds up the compositing of windows in the graphic cards hardware using OpenGL/3D acceleration. Hence the demo of transparent OpenGL windows over video etc.

Now since I posted this video in the 3D interface discussion thread, I rewatched it, and it seems like Microsoft already did exactly the same in 1999. I guess the Radeon wasn't available back then, but they did it with a lot of windows and at a very decent speed (actually the live window resizing made me jealous too).

So Kelly's opinion that a Rage 128 should be able to handle that much windows in 3D doesn't seem so far fetched any more. How was that possible?

[Hilzoy]

Thanks for the great explanation, Moki. And thanks as well for being willing to explain things like this, your licensing policy, and so forth, despite the abuse you sometimes get (for reasons that seem to me totally unfathomable.)
KellyHogan: you do, of course, owe Moki an apology. You say you didn't attack him; this implies either (a) that you don't think that impugning someone's honor (by saying he'd lie for money) and his intelligence (by implying that he thinks that a few posts on a soon-to-be-forgotten MacNN thread will have any appreciable effect on his earnings) is an insult, which tells us a lot about you; or (b) (more likely) that when you say something that's truly out of line you don't have the guts to admit it and apologize, but try to wriggle out of it.
Last off-topic point: if any of you have ever wondered why there are virtually no identifiable women on these boards, just look at the frequency with which people try to insult KellyHogan by suggesting he's female.

[mbryda]

Originally posted by Developer:
<STRONG>OK, I will take over Kelly's point of view for a second.
this video in the 3D interface discussion thread, I rewatched it, and it seems like Microsoft already did exactly the same in 1999. I guess the Radeon wasn't available back then, but they did it with a lot of windows and at a very decent speed (actually the live window resizing made me jealous too).

So Kelly's opinion that a Rage 128 should be able to handle that much windows in 3D doesn't seem so far fetched any more. How was that possible?</STRONG>

Interesting... According to the site:
"The current base implementation runs on Windows PCs with a 400 MHz Intel Pentium II processor, 128 MB of RAM, and AGP support. We initially used the NVIDIA Riva TNT2 graphics accelerator with 32MB of memory and AGP texturing support. With this setup we achieved frame rates above 20 frames per second (fps) without substantial optimization of the code. The newest emerging graphics accelerator cards will certainly provide "real-time" updates of well over 30 fps and with with even less texture-mapping bottlenecks."

I'm just curious as to how the TNT 2 compares to the RAGE series of GPU's?

-Matt

[Kickaha]

Originally posted by Developer:
<STRONG>OK, I will take over Kelly's point of view for a second.

As far as I understand QE it speeds up the compositing of windows in the graphic cards hardware using OpenGL/3D acceleration. Hence the demo of transparent OpenGL windows over video etc.

Now since I posted this video in the 3D interface discussion thread, I rewatched it, and it seems like Microsoft already did exactly the same in 1999. I guess the Radeon wasn't available back then, but they did it with a lot of windows and at a very decent speed (actually the live window resizing made me jealous too).

So Kelly's opinion that a Rage 128 should be able to handle that much windows in 3D doesn't seem so far fetched any more. How was that possible?</STRONG>

Take a close look - do *you* see any non-square windows? They all seem to be about 512x512 maximum too. Note that they're all painfully small for real work.

This fits with what we've all been saying... *if* you had power of 2 sized windows, the Rage 128 would probably be able to handle some of the load... on AGP. The lack of real world ^2 sized square windows means that you're pumping an *incredible* amount of wasted RAM through the bus. (Remember, that 225% of normal was an *average*, not a maximum... that's what you'd *expect* to be wasting.) That alone is going to significantly impact your performance, and it only gets worse (read: fugeddaboudit) on PCI.

Remember, MS is the House of Vapor Demos. Hell, I can demo what they showed running on a Rage Pro if you'd like... it just has to be pre-rendered.

[moki]

Originally posted by Developer:
<STRONG>Now since I posted this video in the 3D interface discussion thread, I rewatched it, and it seems like Microsoft already did exactly the same in 1999. I guess the Radeon wasn't available back then, but they did it with a lot of windows and at a very decent speed (actually the live window resizing made me jealous too).

So Kelly's opinion that a Rage 128 should be able to handle that much windows in 3D doesn't seem so far fetched any more. How was that possible?</STRONG>

As you know (being a developer), there's a huge chasm between a demo and a shipping product. there is a reason they demo'd it in 1999 and still haven't shipped it in any working form.

[Developer]

Originally posted by moki:
<STRONG>

As you know (being a developer), there's a huge chasm between a demo and a shipping product. there is a reason they demo'd it in 1999 and still haven't shipped it in any working form. </STRONG>

I would have hoped they didn't ship it, because they realized the idea [of a 3D interface] is crap.

Anyway, I realize that the windows - while not strictly squared - are probably not larger then 512x512, and that he never interacts with the applications in the video. Nevertheless it's interesting to see who already experimented with the basic idea.

ps:
nomen non semper est omen

[ 05-14-2002: Message edited by: Developer ]

[KellyHogan]

Originally posted by mbryda:
<STRONG>

Interesting... According to the site:
"The current base implementation runs on Windows PCs with a 400 MHz Intel Pentium II processor, 128 MB of RAM, and AGP support. We initially used the NVIDIA Riva TNT2 graphics accelerator with 32MB of memory and AGP texturing support. With this setup we achieved frame rates above 20 frames per second (fps) without substantial optimization of the code. The newest emerging graphics accelerator cards will certainly provide "real-time" updates of well over 30 fps and with with even less texture-mapping bottlenecks."

I'm just curious as to how the TNT 2 compares to the RAGE series of GPU's?

-Matt</STRONG>

In 1999 I has a 416 Mhz overclocked Celeron with Riva TNT 16MB. It was slower than a Rage 128 by a little bit so the TNT 2 should be about the same level since it was released at the same time. It is amazing to see the Rage 128 still shipping.

As for Moki's latest answer, I'm not very satisfied. Firstly the Radeon Mobility lacks many of the features of the desktop version, including less bandwidth, slower RAM and no transform and lighting. If the Radeon Mobility is supported by QE then why not the Rage 128. The speed difference is not that great in Quake benchmarks. If it were 3X then I would understand, but the difference isn't so different that the Radeon Mobility should be able to handle QE and the Rage 128 not.

And the other question I asked was regarding higher desktop resolutions within one or two years. Would this make today's Geforce 2MX and Radeon 32MB useless and unsupported too? If so, QE is probably a bloated technology one step too far.

A couple of developers claim they don't mind QE gobbling up resources and making slightly older hardware redundant because they can see where it is going. It sounds like Pro-EU politicians who like where they are taking people yet don't want to tell people where they are taking them. Coudl you at least hint where does QE take the end user or is it just to have animated smilies one day?

[KellyHogan]

Originally posted by Developer:
<STRONG>

So Kelly's opinion that a Rage 128 should be able to handle that much windows in 3D doesn't seem so far fetched any more. How was that possible?</STRONG>

They won't want to answer that in a reasonable way without inciting a flame war. When they got you cornered then you're the one to blame.

'I was just sitting down at the dinner table and said to my wife 'That supper was good enough for Jehovah!'.

[Kickaha]

Kelly, *WHACK* read *WHACK* my *WHACK* response *WHACK* above *WHACK*.

Same freakin' technical issue you keep dodging and burying your head in the sand over.

*WHACK WHACK WHACK*

Hmmm. Nope. No effect. Still not getting through, is it?

[KellyHogan]

After watching that Microsoft technology demonstration I think all the people insulting me now better watch the video and give me a clear cut explanation.

That video basically vindicated everything I have been saying (this tends to happen on these forums time and time again). That video showed Windows 2000 running current applications mapped live onto 2D windows floating in 3D space with live resizing, fluid animations, fantastic multi-tasking and running many apps with no slow down while using sound effects too. This was all done on a 16MB Riva TNT 2 which the engineers called 'consumer grade graphics card'. This was done in 1999 and Apple have no claim to being inventive with Quartz Extreme.

Now I'm going to want an explanation. The answer can only be two things. One, Quartz Extreme is bloated rubbish and badly implemented. Or two, Apple wants people to upgrade their hardware and like times before is abandoning perfectly suitable machines.

Watch the video, then explain. Don't give fancy physics and swear words and then mock me when I retaliate in the same manner. I don't expect any apologies at all because I'm not hurt.

Thanks Developer for posting that link.

[Kickaha]

Dear god almighty on a flaming pogo stick.

Am I invisible? Or do you just have your head so far in the sand that you can't even acknowledge the 'fancy words and physics'... which by the way, the rest of us here in reality call 'facts'.

Cripes. I give up. There can't be more than three firing neurons in this guy's skull.

Rage 128.

Only supports square textures of certain sizes.

Square windows of those sizes rare in real life.

Attempts to bypass this limitation are going to be slow.

Too much wasted RAM because of this.

Definitely too slow to push wasted RAM over PCI.

Almost certainly too slow to push wasted RAM over AGP.

Get it? (Oh wait... lim-i-ta-tion has four syllables. My bad.)