[geran]

What is the minimum requirements for Core Image, will the ATi 9200 card work? Cant find any information on the apple website

[Chuckit]

They seem to have gotten rid of the requirements on the new, prettified Core Image page. From the original:

Supported graphics cards:

* ATI Radeon 9800 XT
* ATI Radeon 9800 Pro
* ATI Radeon 9700 Pro
* ATI Radeon 9600 XT
* ATI Radeon 9600 Pro
* ATI Mobility Radeon 9700
* ATI Mobility Radeon 9600
* NVIDIA GeForce 6800 Ultra
* NVIDIA GeForceFX Go 5200
* NVIDIA GeForceFX 5200 Ultra

These cards are available in today’s PowerBooks, Power Mac G5s and both the 17-inch and 20-inch iMac.

[U n i o n 0015]

What exactly is Core Image? Even after reading through all of Apple's press material, I could never quite understand what it exactly does.

[Chuckit]

It offers a simple, scalable API for processing images with the GPU.

[Millennium]

Originally posted by Chuckit:
They seem to have gotten rid of the requirements on the new, prettified Core Image page. From the original:

It's not that they were ever required, per se; it's just that these are the cards which will be hardware-accelerated. Apple has said in the past that it intends to provide an emulator so that older machines can run CoreImage as well, but it will be much slower on these.

[Millennium]

(oops; hit Reply too soon)

Given that situation, Geran, it looks as though CoreImage wouldn't run accelerated on your 9200, but it would still work via the emulator.

[Thinine]

It's not an emulator.

[Millennium]

Originally posted by Thinine:
It's not an emulator.

What is it, then? It would seem to me as though an emulated graphics card with the appropriate driver would probably be the easiest way for Apple to go.

[TETENAL]

Originally posted by Millennium:
What is it, then?

A software implementation.

[jtwiskowski]

The ATi Radeon available on the Mac mini is not the Radeon Mobility that is on the iBooks. Just because the Radeon Mobility wasn't Core Image does that mean the "full-fledged Radeon" as Apple calls it, in Radeon 9200 is not Core Image compatible?

[Catfish_Man]

Originally posted by jtwiskowski:
The ATi Radeon available on the Mac mini is not the Radeon Mobility that is on the iBooks. Just because the Radeon Mobility wasn't Core Image does that mean the "full-fledged Radeon" as Apple calls it, in Radeon 9200 is not Core Image compatible?

The Radeon 9200 doesn't support the necessary pixel shader features for Core Image.

[Disgruntled Head of C-3PO]

What did the first G5 duals ship with? A 9600 Pro right? Is that FULLY supported?

[Catfish_Man]

Originally posted by Disgruntled Head of C-3PO:
What did the first G5 duals ship with? A 9600 Pro right? Is that FULLY supported?

Yup. It's no performance monster, but it'll work. The 9600 mobility in my PB does too

[Chuckit]

Originally posted by jtwiskowski:
The ATi Radeon available on the Mac mini is not the Radeon Mobility that is on the iBooks. Just because the Radeon Mobility wasn't Core Image does that mean the "full-fledged Radeon" as Apple calls it, in Radeon 9200 is not Core Image compatible?

Did I not just post the list of supported graphics cards? Did it turn invisible?

[Millennium]

Originally posted by TETENAL:
A software implementation.

That doesn't say much; most emulators are software implementations.

Providing an emulator would be the easiest way Apple could do this, because it would become just another driver for CoreImage, and therefore wouldn't require changes every time the rest of the CoreImage code did. If they chose to do it this way -and the original CoreImage presentations suggested it strongly- then the result would be an software implementation consisting of an emulator.

[jamil5454]

My question is this - will CoreImage speed up OS X responsiveness on radeon 9200s (like it will on newer cards)?

An article from Anandtech stated that OS X Tiger will do all its gui processing on the GPU, only if your video card supports it. Currently, OS X 10.3 gui processing only partially uses the video card, and is still very much CPU bound.

[Millennium]

Originally posted by jamil5454:
My question is this - will CoreImage speed up OS X responsiveness on radeon 9200s (like it will on newer cards)?

No, but it won't speed up responsiveness on newer cards either. That's not what CoreImage is for.

What you're thinking of is Quartz Extreme 2D, another technology slated for Tiger. I don't think it'll work on your card, but you should still be able to use the older Quartz Extreme compositor, so it shouldn't hurt you.

An article from Anandtech stated that OS X Tiger will do all its gui processing on the GPU, only if your video card supports it.

All true, but that's Quartz Extreme 2D, not CoreImage. The two technologies are somewhat related, but they do very different things.

Currently, OS X 10.3 gui processing only partially uses the video card, and is still very much CPU bound.

Quartz Extreme, the technology introduced in Jaguar and still used in Panther, only uses the video card for compositing. This can provide a significant speed boost, but most of the actual drawing is still done by the CPU. That's what the Anandtech article is talking about.

[Catfish_Man]

Originally posted by Millennium:
That doesn't say much; most emulators are software implementations.

Providing an emulator would be the easiest way Apple could do this, because it would become just another driver for CoreImage, and therefore wouldn't require changes every time the rest of the CoreImage code did. If they chose to do it this way -and the original CoreImage presentations suggested it strongly- then the result would be an software implementation consisting of an emulator.

From what I've read, it's a very slick implementation. Image "kernels" are compiled on the fly to the available hardware, which can be pixel/vertex shaders of varying tech levels, altivec, or even (iirc) multiple cpu altivec. I guess that *could* be considered emulation, but I can see why someone would prefer to refer to it as a software implementation.

[Angus_D]

Originally posted by Millennium:
What is it, then? It would seem to me as though an emulated graphics card with the appropriate driver would probably be the easiest way for Apple to go.

That's because you're not a developer and you don't know what you're talking about. Seriously, this makes no sense whatsoever.

[Angus_D]

Originally posted by Catfish_Man:
From what I've read, it's a very slick implementation. Image "kernels" are compiled on the fly to the available hardware, which can be pixel/vertex shaders of varying tech levels, altivec, or even (iirc) multiple cpu altivec. I guess that *could* be considered emulation, but I can see why someone would prefer to refer to it as a software implementation.

It's not an emulator though. It's just a different code path.

Core Image leverages OpenGL to provide a state-of-the-art image processing environment, making it easier for you to take advantage of the power of today's programmable GPUs. Core Image compiles image processing programs—or kernels—at runtime, globally optimizing across multiple kernels and taking advantage of the GPU whenever possible. It can also dynamically generate optimized code for SMP CPUs when CPU processing is desired.

[Millennium]

Originally posted by Angus_D:
That's because you're not a developer and you don't know what you're talking about. Seriously, this makes no sense whatsoever.

You wound me, Angus. Actually, I do know what I'm talking about with this.

You're correct, of course, about the technology compiling "kernels" (interesting use of that term, by the way) at runtime for graphics cards. However, this would seem to support my argument, not yours, as this kind of architecture lends itself perfectly to emulation. If there isn't a supported graphics card present, you simply target the emulator instead of a card in the compilation step. How does this not make sense?

[Angus_D]

Originally posted by Millennium:
You're correct, of course, about the technology compiling "kernels" (interesting use of that term, by the way) at runtime for graphics cards. However, this would seem to support my argument, not yours, as this kind of architecture lends itself perfectly to emulation. If there isn't a supported graphics card present, you simply target the emulator instead of a card in the compilation step. How does this not make sense?

It doesn't make sense because it'd be rather crazy to implement the entire OpenGL shader spec in software when you're just doing specific operations which can be better optimized by doing them specifically.

Emulation implies that the CPU is imitating the graphics hardware. I don't see why it'd make any sense to conceptualise it like that. CoreImage has certain operations to perform. Depending on the hardware available, it may be more efficient to perform those operations through the use of pixel shaders (little programs that run on your graphics card) or normal programs that run on your general purpose CPU.

Where's the pretending to be another system in that?

[Millennium]

Originally posted by Angus_D:
It doesn't make sense because it'd be rather crazy to implement the entire OpenGL shader spec in software when you're just doing specific operations which can be better optimized by doing them specifically.

Short-term, yes, it would be crazy. In fact, it would be lunacy. Long-term, however, it makes a fair bit of sense, particularly when you're experimenting with shaders to do work elsewhere in the OS.

Emulation implies that the CPU is imitating the graphics hardware. I don't see why it'd make any sense to conceptualise it like that.

For those operations which require a graphics card, the concept of an emulated graphics card makes perfect sense.

CoreImage has certain operations to perform. Depending on the hardware available, it may be more efficient to perform those operations through the use of pixel shaders (little programs that run on your graphics card) or normal programs that run on your general purpose CPU.

Where's the pretending to be another system in that?

If pixel shaders turn out to be the more efficient method, then this allows you to continue using pixel shaders even on systems which don't ordinarily support them. This allows you to simplify the CoreImage code considerably, since you don't have to code in as many special cases where you need to check whether there's a supported graphics card. In addition to providing less opportunity for bugs to creep in -and God knows Apple needs this, given the relatively shoddy state of their QA nowadays- it also results in a slight speed boost, which isn't critical for CoreImage itself but will be very important for CoreVideo.

Of course, this probably isn't as efficient on machines which have to actually use the emulator (i.e. unsupported machines). If you consider that Apple is a hardware company, however, and makes its money by selling new Macs, suddenly this starts to seem more sensible, even if it's somewhat underhanded. Users of these machines won't be left completely out in the cold -which is good for PR- but will feel increased pressure to upgrade to newer machines.

[lenox]

I'm not sure I'd use the term 'emulator' here either.

[Millennium]

Originally posted by lenox:
I'm not sure I'd use the term 'emulator' here either.

Technically, it fits. It's not the way we normally use the term nowadays, where an "emulator" is thought of as a full application that runs programs for some other platform, but it fits.

This is not the first time that Apple has done something like this, nor is it even the most deeply-embedded emulator that has ever been in the OS. Ever since the days of the first PowerPC machines, the Mac OS had an emulator embedded into it, so that it could run apps written for the 680x0 processors which had preceded the PPC line. This was possible because the 68K and PPC apps used the same API and very similar hardware architectures aside from the core CPU; to attempt it with a radically-different API and architecture, such as Wintel, borders on impossibility, to say the least.

OSX doesn't include this 680x0 emulator anymore, though the version of OS9 which runs in Classic may still have it. It's been so long since I ran a 680x0 app that I don't know for sure. But regardless, Apple is no stranger to emulation. Indeed, it's one of the PowerPC architecture's specialties; the chip was literally designed for it. Is it truly so far-fetched that Apple would revisit this technique -which it has known about and used for many years- so that older machines might be able to make use of hardware which they don't otherwise have?

[bmedina]

We don't say that the G3 emulates a G4 when running Altivec code. It just uses a different code path to achieve the same result in a slower fashion.

This is basically the same thing; just replace G3 with CPU and G4 with GPU.

[yikes600]

Originally posted by bmedina:
We don't say that the G3 emulates a G4 when running Altivec code. It just uses a different code path to achieve the same result in a slower fashion.

This is basically the same thing; just replace G3 with CPU and G4 with GPU.

A G3 does not emulate a G4. A G3 cannot run Altivec code.

[Catfish_Man]

Originally posted by bmedina:
We don't say that the G3 emulates a G4 when running Altivec code. It just uses a different code path to achieve the same result in a slower fashion.

This is basically the same thing; just replace G3 with CPU and G4 with GPU.

G3s crash if you run altivec code.

[CharlesS]

Originally posted by Catfish_Man:
G3s crash if you run altivec code.

What he should have said is that we don't say that an AltiVec-enhanced application is emulating a G4 when it runs on a G3. It just uses a different code path to achieve the same result in a slower fashion. An example would be iTunes, when converting sound files to AAC - if you're on a G4, it uses a method which is "optimized for Velocity Engine" to do so, whereas if you run it on a G3, it does something else which is slower. Voilà.

Just replace iTunes with CoreImage and AltiVec with pixel shaders.

There is absolutely no evidence whatsoever that CoreImage would be emulating the pixel shaders on a GPU, and it would be really, really stupid for them to do this because it would be dog slow.

[bmedina]

Originally posted by Catfish_Man:
G3s crash if you run altivec code.

Sorry for the ambiguity; I had to post quickly. But that's why I said, "It just uses a different code path to achieve the same result in a slower fashion." Different code path = non-altivec code. But I think the analogy stands.

[Millennium]

Originally posted by bmedina:
We don't say that the G3 emulates a G4 when running Altivec code. It just uses a different code path to achieve the same result in a slower fashion.

Indeed we don't, because a G3 cannot run AltiVec code at all (if you try, the application tends to crash). In this case, it makes little sense for developers to code an emulator when they could simply run a code path. AltiVec is highly specialized, and making an emulator for something which you won't use very often does not make sense.

Actually, Apple does make an AltiVec emulator, but it's a developer tool only (not bundled into the OS) and I'm not sure they distribute it anymore. It was fairly popular back in the first days of the G4 chip, though, when most developers still had G3 machines and needed to test their AltiVec code.

This is basically the same thing; just replace G3 with CPU and G4 with GPU.

No, actually it's not the same thing. Not at all. For one thing, CoreImage is an OS feature expected to run on all Macs, whereas AltiVec is a hardware feature which is not expected to run everywhere. Furthermore, AltiVec is very specialized hardware, useful only in particular situations, whereas CoreImage is much more general-purpose and -it's believed- will see a lot more action than AltiVec by itself ever has.

In particular, AltiVec is supposed to drive hardware sales, while CoreImage is supposed to drive software sales. These are very different beasts. When you're driving hardware sales, you want features to run on as little hardware as possible (preferably only the hardware you're selling). When you're driving software sales, you want feature to run on as wide a number of systems as you possibly can, so that you can sell it to as many people as possible.

Given this situation, it makes perfect sense to code up an emulator for a graphics card in this situation, because it simplifies your code dramatically. It gets rid of the branching code paths, thus reducing the possibility for bugs (which, as I pointed out and no one has argued against, Apple sorely needs right now). At most, an emulator would need to be coded twice, once for AltiVec-enabled machines and once for others. After this, all CoreImage code and new effects need to be coded only once, with a single code path, and they will automatically run on any CoreImage-enabled machine, taking maximum advantage of the hardware on that machine, without having to know what's on it, because the CoreImage compiler itself handles all of that.

Are you trying to tell me that Apple would not do something like this? Part of the point of OSX is that it's supposed to be easy to code for as well as to use; witness Cocoa, AppleScript Studio, and Automator. With an emulator, this becomes another link in the chain.

I am not trying to mince words, or use a different version of "emulator" than you. I am saying that Apple itself has already committed itself to a graphics-card emulator -with the word "emulator" being a definition that you and I can both agree on- to handle CoreImage effects on machines without a supported graphics card. And furthermore, I have outlined exactly why it makes perfect sense to do this, and the funny thing is, you don't even seem to be arguing against me on that. What the heck are we arguing for?

[Kate]

Correct me if I'm wrong, but Apple hasn't used an emulator for this yet. Has it? So far there are different code paths...are there hints they will change this until the release of Tiger? Would be news to me. There was no mention of it I could remember in the CoreImage sessions....

[Millennium]

Originally posted by Kate:
Correct me if I'm wrong, but Apple hasn't used an emulator for this yet. Has it? So far there are different code paths...are there hints they will change this until the release of Tiger? Would be news to me. There was no mention of it I could remember in the CoreImage sessions....

They already talked about an emulator, during the original CoreImage announcement. It is possible that they changed this since that time (though it would be a very poor design decision), but if so then I don't recall them mentioning it.

[Thinine]

No, you're wrong Millennium. You have no idea what you're talking about.

[Millennium]

Originally posted by Thinine:
No, you're wrong Millennium. You have no idea what you're talking about.

Do I have to dig back through my archives and find the links for your folks? I remember this quite vividly.

[TETENAL]

A GPU emulator is non-sense. Period.

[bseely]

Originally posted by Millennium:
Do I have to dig back through my archives and find the links for your folks? I remember this quite vividly.

Please do.

They will not be building a GPU emulator. They will just implement the feature in software instead of passing the instructions to the card. That is *not* the same as writing an emulator.

[arekkusu]

FWIW, Apple has shipped an ARB_fragment_program software implementation since 10.3.4. You already have it in Panther.

Ignoring the whole "emulator" argument for a second, implementing OpenGL in software is nothing new. What is missing now is GLSL.

Actually, there are a good many things missing from the software renderer (as it only fully implements OpenGL 1.1) but long term it would be great if it fully implemented 2.0 and a superset of every hardware GPU's capability. At that point, you might be able to call it an emulator (although that's a whole different discussion of what "emulate" means.)

[CharlesS]

Originally posted by Millennium:
No, actually it's not the same thing. Not at all. For one thing, CoreImage is an OS feature expected to run on all Macs, whereas AltiVec is a hardware feature which is not expected to run everywhere.

CoreImage is a piece of software (which happens to be part of the OS) that is expected to run on all Macs. Similarly, iTunes is a piece of software which is expected to run on all Macs.

iTunes uses a different mechanism to encode AAC files depending on whether AltiVec is present or not. Similarly, CoreImage will almost certainly use a different mechanism to do its thing depending on whether the pixel shaders are there or not.

Let's get our analogies straight. Compare software with software, not software (CoreImage) with hardware (AltiVec).

[TC]

http://developer.apple.com/macosx/tiger/

Enter Core Image, a robust framework in Tiger for ultra-fast high-precision image processing, from basic operations such as color adjustments all the way to advanced high-motion visual effects. Core Image leverages OpenGL to provide a state-of-the-art image processing environment, making it easier for you to take advantage of the power of today's programmable GPUs. Core Image compiles image processing programs—or kernels—at runtime, globally optimizing across multiple kernels and taking advantage of the GPU whenever possible. It can also dynamically generate optimized code for SMP CPUs when CPU processing is desired.

I agree that emulation is probably not the correct word as it sounds like it generates hardware specific code from the same source code. If you don't have a compatible graphics card or desire CPU processing then it generates code for your processor.

It also looks like it will generate very different code depending on which graphics card you have, that comes from reading ATI's web site. It sounds like the technology used by Core Image has the ATI title of SMARTSHADER. On this page they include info on their technologies:
http://www.ati.com/companyinfo/gloss...#smartshader20

They have 3 different versions of smartshader, 2.0, 2.1 and HD. Sounds like Core Image would dynamically generate code to use the features of the available card.
So another future issue will not just be whether your card supports Core Image but whether it is fully used for a core image effect or part of it is passed of to the processor.
For example maybe a card which has SmartShader HD giving it "10x more instructions than was possible in previous products" may mean that it can handle running a lot more effects in Motion simultaneously than a card which has SmartShader 2.1?
Apple recommends a minimum of a Radeon 9800 for Motion and that card has SmartShader 2.1 compared to 2.0 of 9600. So again the 9600 may be up to the tast of a few effects but the 9800 could handle a lot more.

And no I can't use the phrase sounds like any more in one post.

[Toyin]

Originally posted by Millennium:
No, but it won't speed up responsiveness on newer cards either. That's not what CoreImage is for.

What you're thinking of is Quartz Extreme 2D, another technology slated for Tiger. I don't think it'll work on your card, but you should still be able to use the older Quartz Extreme compositor, so it shouldn't hurt you.

All true, but that's Quartz Extreme 2D, not CoreImage. The two technologies are somewhat related, but they do very different things.

Quartz Extreme, the technology introduced in Jaguar and still used in Panther, only uses the video card for compositing. This can provide a significant speed boost, but most of the actual drawing is still done by the CPU. That's what the Anandtech article is talking about.

Does Quartz Extreme 2D exist? Quartz extreme was really pushed as a prime feature in Panther. There's no mention of Quartz Extreme 2D on Apples Tiger page, leading me to believe that a) It doesn't exist or b) It's been pushed back to a later release.

[Kate]

Originally posted by Toyin:
Does Quartz Extreme 2D exist?

They did present it in the sessions, They explicitly called it Quartz Extreme 2D , it was shown in graphics depicting the architecture of the new graphics subsystem. They showed some detail on how it works and what's new about it and were presenting this with much confidence.
Judging from this I'd say it exists.

[Catfish_Man]

Originally posted by Toyin:
Does Quartz Extreme 2D exist? Quartz extreme was really pushed as a prime feature in Panther. There's no mention of Quartz Extreme 2D on Apples Tiger page, leading me to believe that a) It doesn't exist or b) It's been pushed back to a later release.

/me looks at horrendous pre-release drawing glitches.

It exists... (and no, I have no idea why they aren't pushing it more. It's pretty damn cool, from what I've seen in the WWDC stream that talks about it)

[Toyin]

Originally posted by Catfish_Man:
/me looks at horrendous pre-release drawing glitches.

It exists... (and no, I have no idea why they aren't pushing it more. It's pretty damn cool, from what I've seen in the WWDC stream that talks about it)

Originally posted by Kate:
They did present it in the sessions, They explicitly called it Quartz Extreme 2D , it was shown in graphics depicting the architecture of the new graphics subsystem. They showed some detail on how it works and what's new about it and were presenting this with much confidence.
Judging from this I'd say it exists.

Thanks! I'm looking forward to this!

[larry k.]

Has anyone experienced using 10.4 beta's on lower and higher end video cards to compare? Is there a noticeable difference in the way effects occur or is it basically they work if you're compatible and they dont if you're not?

For example, I have a 9600 xt. While it is listed as being compatible it is closer to the mid to lower range in video cards now. If I were to upgrade to a 6800gt or an x800xt would I notice the operating system and effects working more smoothly (once 10.4 is out) or would I only notice a difference if I used more professional demanding applications?

[pliny]

Originally posted by Chuckit:
It offers a simple, scalable API for processing images with the GPU.

And I bet one reason requirements have been removed is that they are changing them to allow a wider range of machines to take advantage of it, which means the supported features are not complete/set in stone.

[Kate]

Originally posted by larry k.:
Has anyone experienced using 10.4 beta's on lower and higher end video cards to compare?........

A comparison would need to have the CoreImage and Quartz 2D Extreme software to be close to release, which it is not. Hardware support aims at getting more on-board than expected it seems.

Not to mention that not everything is available in all currently available developer versions.
Hard to say what the final state will be.

[yikes600]

Originally posted by pliny:
And I bet one reason requirements have been removed is that they are changing them to allow a wider range of machines to take advantage of it, which means the supported features are not complete/set in stone.

The 9200 hardware can't do shaders, so for people hoping Apple will add it to the list of supported cards, it won't ever happen. The reason Apple removed the list is so that potential mini buyers aren't deterred.

[Millennium]

Originally posted by yikes600:
The 9200 hardware can't do shaders, so for people hoping Apple will add it to the list of supported cards, it won't ever happen. The reason Apple removed the list is so that potential mini buyers aren't deterred.

Also, CoreImage will still work on machines which don't have graphics cards capable of working with pixel shaders. It simply won't be accelerated on these machines. That includes the Mini; CoreImage will work, but it won't be accelerated.

I agree with you that Apple probably removed the list so that people wouldn't be as quick to realize that they'll be selling current machines that won't be able to take advantage of hardware acceleration in CoreImage. But that list has always been about requirements for acceleration in CoreImage, not CoreImage itself. This is something Apple has made clear from the beginning.

[pliny]

All you half empty types.