[timmerk]

According to Apple Insider:

Native Graphics Card Support

While Apple began introducing G5-based computers in June of last year, a G5 compatible version of Virtual PC had yet to ship a year later. It was about this time that Redmond, Wash.-based Microsoft began feeling pressure from Apple to get the product out the door, sources said. With current and potential G5 customers miffed over a lack of Virtual PC support, and an imminent release of the iMac G5 around the corner, Microsoft began to trim around the fat.

One of the key features to hit the chopping block was native graphics card support. Although Virtual PC 7.0 does deliver faster, cleaner graphics, users will find that the software still emulates the S3 Virge chipset from the late 90s, with no 3D acceleration. Sources said that native graphics support remains under development, but is unlikely to surface for many months.

see http://appleinsider.com/article.php?id=651

[alphasubzero949]

Now should this surprise anyone?

Typical of M$.

[RonnieoftheRose]

Originally posted by alphasubzero949:
Now should this surprise anyone?

Typical of M$.

I've been saying this for weeks but my words fell on deaf ears. It is impossible to get hardware graphics acceleration without a complete rewrite of the application. As long as it emulates an HX/FX Intel chipset it is impossible to send data across AGP. To change that the app would have to be rewritten entirely to emulate a newer chipset, BX or later.

[Millennium]

Oh, well.

Anyone else remember when VPC3 had native 3dfx support? I remember trying to play the FFVIII demo with it. Pretty pictures, but awful framerate.

[goMac]

Originally posted by RonnieoftheRose:
As long as it emulates an HX/FX Intel chipset it is impossible to send data across AGP. To change that the app would have to be rewritten entirely to emulate a newer chipset, BX or later.

I'm sorry, but you're completely wrong on this point.

You should never ever ever give an application direct access to a slot, so it doesn't matter what kind of slot the graphics card is on. Rather, its better to use the built in OS drivers for graphics, and forward across those, which creates enough of a degree of virtualization that the bus does not matter. Not to mention this would be impossible anyway because Apple graphics cards do not work with Windows.

[RonnieoftheRose]

Originally posted by goMac:
I'm sorry, but you're completely wrong on this point.

You should never ever ever give an application direct access to a slot, so it doesn't matter what kind of slot the graphics card is on. Rather,

I can't believe how you keep thinking you know something about these matters yet post totally wrong opinions.

This is the nail in your coffin.

its better to use the built in OS drivers for graphics, and forward across those, .

This won't be possible emulating an old chipset that doesn't support AGP. You can't pass anything from Windows to the Mac and back if the chipset being emulated is pre-AGP. Impossible. Impossible. Impossible. Repeat that until it gets through to your head. Built in OS drivers for graphics? On what? An HX/FX chipset? The Windows drivers won't see any graphics hardware in VPC running on your Mac is the mobo chipset is older than AGP.

End of story.

[RonnieoftheRose]

Originally posted by Millennium:
Oh, well.

Anyone else remember when VPC3 had native 3dfx support? I remember trying to play the FFVIII demo with it. Pretty pictures, but awful framerate.

Because sending data across PCI is possible. AGP is not.

[fiesta cat]

*hrmph*

Aggravating, but not surprising.

[Truepop]

this is very disappointing. but at least it's an improvement.

[Angus_D]

Originally posted by goMac:
I'm sorry, but you're completely wrong on this point.

Stop making an idiot of yourself and release some software already.

[Eug Wanker]

Originally posted by alphasubzero949:
Now should this surprise anyone?

Agreed, native 3D support was a pipedream for VPC 7.

Typical of M$.

I would have expected no native 3D support in VPC 7 whether it was Microsoft, Connectix, or Apple who did the programming.

[goMac]

Originally posted by RonnieoftheRose:
This won't be possible emulating an old chipset that doesn't support AGP. You can't pass anything from Windows to the Mac and back if the chipset being emulated is pre-AGP. Impossible. Impossible. Impossible. Repeat that until it gets through to your head. Built in OS drivers for graphics? On what? An HX/FX chipset? The Windows drivers won't see any graphics hardware in VPC running on your Mac is the mobo chipset is older than AGP.

You don't really get it.. do you...

The driver within Virtual PC receives draw commands. These may be normal 2D drawing, OpenGL, or DirectX. No where is it an emulated card. It is simply a wrapper for the OS draw functions. This is the same reason you can't run a DirectX game at all in VPC because it is not actually a fully emulated card.

There aren't any raw PCI commands being sent through. Get this through your head. It doesn't matter whats on the Mac side because VPC is piping them through the OS draw routines anyway, which already have drivers for whatever the graphics card is on whatever bus.

The only reason the Voodoo card worked was because the wrapper class would switch modes and allow hardware access.

This is why you can't run any DirectX games at all in VPC. You can't even get into a DirectX mode. There are no DirectX commands for the card to map to. You could do OpenGL mapping, but if the game is in OpenGL, its probably on Mac anyway.

You just don't get it. With virtualization it doesn't matter what is in the virtual machine. It could be a virtual PCI Express card on a Blue and White G3 for all the emulator cares. As long as you have the video card driver in place, it will take the draw commands and forward them to the Mac OS, which will draw them on the screen using whatever driver the OS is using. Adding acceleration would mean wrapping to native functions on the graphics card. The reason 3D graphics acceleration probably got cut is it would be a pain in the neck mapping DirectX because there is nothing to map to in Mac OS. The only way to do it would be an OpenGL bridge.

Stop talking sending data over a PCI slot when thats not the point. The point is you forward to the native OS drivers, NOT the PCI slot. The virtual driver sends generic draw commands like OpenGL commands and 2D commands, does any translation required, and ships them into the OS X display driver. There is no raw PCI data entering the equation anywhere.

Are we really done yet?

[RonnieoftheRose]

Originally posted by goMac:
You don't really get it.. do you...

The driver within Virtual PC receives draw commands.

I only needed to read the first paragraph and a half before I cracked up. VPC doesn't receive any draw commands from anywhere and can't accelerate Open GL. The CPU, S3 Trio and all components are emulated by the CPU alone. Your Mac's graphic card only displays VPC's working window. Everything within the window is rendered on the CPU. There is no GPU work being done at all, even in this new version. Any improvements to drawing in this version are solely due to some improved code running on the CPU.

And MS has admitted that this version will run slower on some machines. Like I said, that's why they up'd the requirements to 700MHz.

Keep trying. This one was hilarious:

The point is you forward to the native OS drivers, NOT the PCI slot.

Of course native Windows drivers. And then communication with the PCI slot via those drivers. But PCI still has to be emulated, which it was in VPC3. It is not in latter version. AGP is impossible to communicate with simply, like I said 100 times, because a pre-AGP mobo chipset is being emulated. You can load all the drivers in VPC you want and you'll never be able to send drawing commands to AGP.

No doubt you'll keep going on with pseudo-technical garbage.

[goMac]

Originally posted by RonnieoftheRose:
I only needed to read the first paragraph and a half before I cracked up. VPC doesn't receive any draw commands from anywhere and can't accelerate Open GL. The CPU, S3 Trio and all components are emulated by the CPU alone. Your Mac's graphic card only displays VPC's working window. Everything within the window is rendered on the CPU. There is no GPU work being done at all, even in this new version. Any improvements to drawing in this version are solely due to some improved code running on the CPU.

And MS has admitted that this version will run slower on some machines. Like I said, that's why they up'd the requirements to 700MHz.

Keep trying. This one was hilarious:



Of course native Windows drivers. And then communication with the PCI slot via those drivers. But PCI still has to be emulated, which it was in VPC3. It is not in latter version. AGP is impossible to communicate with simply, like I said 100 times, because a pre-AGP mobo chipset is being emulated. You can load all the drivers in VPC you want and you'll never be able to send drawing commands to AGP.

No doubt you'll keep going on with pseudo-technical garbage.

You really don't get it. It's not emulating a full PCI video card. It's acting as a wrapper. If it really was emulating a full PCI graphics card then you would have DirectX support in emulation, which you do not. Stop talking about raw PCI commands because there aren't any raw PCI commands going.

And no, VPC in its current form does not do OpenGL. I mentioned that there would be little point. Most OpenGL games are for Mac anyway, and it would take a little extra work to get OpenGL to draw in the right graphics context. DirectX would be the issue as there is nothing to forward to.

Really, learn how a graphics subsystem works. Warcraft III does not send raw PCI or AGP commands. It uses (on the Mac) OpenGL which is sent into the graphics driver. The point is if the wrapper graphics driver in VPC wanted to, it could forward this to the Mac OS's graphics system, despite being a different style card. OpenGL is nearly the same depending on any card, except for various extra shading extensions that NVidia and ATI added that are only used in very recent games. The type of card would not matter.

Once again, raw PCI data never enters the equation. If you think VPC really emulates a full PCI graphics card you need to go learn how it really works.

And forwarding to the Mac OS does not necessarily mean graphics acceleration. I can run OS X 10.0 on a Wallstreet Powerbook just fine, with 0 graphics acceleration. It still draws just fine on the screen using the Mac OS graphics system. This was before they introduced 2D acceleration for cards that old.

[RonnieoftheRose]

Originally posted by goMac:
[B]You really don't get it. It's not emulating a full PCI video card.

Huh? I didn'y even say it was ???

And no, VPC in its current form does not do OpenGL.

That's what I said ???

You're an effing nutter, mate.

[goMac]

Then what is your problem with what I am saying? Everything is rasterized via the Mac OS. The image on the screen is not rasterized within an emulated graphics card.

[Angus_D]

Originally posted by goMac:
It's not emulating a full PCI video card.

Everybody has always claimed it was emulating an S3 Trio. If you read anything different, you're on crack.

Originally posted by goMac:
Then what is your problem with what I am saying? Everything is rasterized via the Mac OS. The image on the screen is not rasterized within an emulated graphics card.

Of course it is. Virtual PC emulates an S3 Trio. It has a bit of software that behaves like an S3 Trio. This software runs on your CPU. Of course this means that it's a bit slow and pants. This presumably goes into a big buffer somewhere which is then displayed inside a normal CG window.

It seems that you're claiming that Virtual PC intercepts the Win32 API calls for drawing and converts them into Mac OS calls. Well, I mean, I didn't read your long diatribes because they were too nonsensical, but that's the impression I got. If this is really what you think, then you're confusing Virtual PC with WINE.

[theolein]

I have an idea that all three of you are talking about different things, but, in typical geek one-upmanship, you don't actually bother to read what the others are saying and instead try to show what clever boys you are by dissing the others.

I assume the actual gist is this (from what I could make out between the pissing matches): The current state of VPC is that the motherboard emulated by VPC (as seen by the windows OS installed) is one that uses an old S3 Virge chipset. The S3 chipset had no AGP, which is why no Windows driver could access that slot, and no Windows software could take advantage of those features. Am I correct so far?

Now, since one can install basically any x86 OS in VPC, it means that the VPC environment emulates a real PC, but an old one. No driver software would be able to use AGP features, because it simply doesn't exist in that environment. (I think this is the bone of contention between you boys. Am I right?)

What VPC would need in order to do AGP, would be a completely new emulated motherboard. That is what Ronnie was talking about, I think. In other words a complete rewrite of the software or a large part of it (I assume there must be a huge amount of optimisation there to get VPC to run quickly). So it is probably not a simple task.

Could Microsoft have done it, since they took their own good time to bring out VPC7? No doubt. But I don't think it's in Microsoft's interest to make VPC as good as it could be.

I am pretty sure MS could make VPC run up to one third of the host system's speed if they really wanted to, and the dual G5 CPU's could make it even faster in certain cases. But that would mean that VPC, running on a 2,5GHz dual G5, would be the equivalent of a 700MHz PC, which would be more than enough for almost all Microsoft applications such as Access, Money, VS.Net, Project etc. It would provide Apple with good PR and be a good way for enterprise customers to migrate away from x86, where MS make almost all of its money.

I think this would be a golden opportunity for someone to work on a new emulator.

[goMac]

Originally posted by Angus_D:
It seems that you're claiming that Virtual PC intercepts the Win32 API calls for drawing and converts them into Mac OS calls. Well, I mean, I didn't read your long diatribes because they were too nonsensical, but that's the impression I got. If this is really what you think, then you're confusing Virtual PC with WINE.

No, it doesn't intercept the Win32 drawing calls, it intercepts the graphics cards drawing calls that are sent to the GPU. VPC does not rasterize once on a virtual GPU in VPC and then send it out to the Mac OS where it is rasterized again along with the Mac OS windowing system, it simply rasterizes right to most likely a GWorld.

[nickm]

But I don't think it's in Microsoft's interest to make VPC as good as it could be.

And why not? VPC allows Windows and Windows software to run on millions of Macs. Microsoft sells lots of Windows software, so what's the problem here?

I suppose you might argue that if Windows emulation was good enough on the Mac that many more people would buy Macs with the confidence that they could run their Windows software. However, when they bought new programs they would be more likely to buy the Mac equivalent than the MS version.

I think this doesn't fly for a couple of reasons. Microsoft probably makes most of their money on the Windows OS and Office Suite. If you want to run Windows software you'll need to buy a Windows OS from MS. Also, if you want the best Office compatibility, you'll want MS Office for Windows or MS Office for Mac. Perhaps a Mac user will buy the Mac version of Photoshop rather than Windows version, but that doesn't really affect MS either way.

In any case, I run Microsoft Streets and Trips in Virtual PC 6 (on a Tibook 800) and I think it runs pretty well.

[RonnieoftheRose]

Originally posted by goMac:
No, it doesn't intercept the Win32 drawing calls, it intercepts the graphics cards drawing calls that are sent to the GPU. VPC does not rasterize once on a virtual GPU in VPC and then send it out to the Mac OS where it is rasterized again along with the Mac OS windowing system, it simply rasterizes right to most likely a GWorld.

This Gworld guy is nuts.

[RonnieoftheRose]

Originally posted by theolein:
I have an idea that all three of you are talking about different things, but, in typical geek one-upmanship, you don't actually bother to read what the others are saying and instead try to show what clever boys you are by dissing the others.

I assume the actual gist is this (from what I could make out between the pissing matches): The current state of VPC is that the motherboard emulated by VPC (as seen by the windows OS installed) is one that uses an old S3 Virge chipset. The S3 chipset had no AGP, which is why no Windows driver could access that slot, and no Windows software could take advantage of those features. Am I correct so far?

Now, since one can install basically any x86 OS in VPC, it means that the VPC environment emulates a real PC, but an old one. No driver software would be able to use AGP features, because it simply doesn't exist in that environment. (I think this is the bone of contention between you boys. Am I right?)

What VPC would need in order to do AGP, would be a completely new emulated motherboard. That is what Ronnie was talking about, I think. In other words a complete rewrite of the software or a large part of it (I assume there must be a huge amount of optimisation there to get VPC to run quickly). So it is probably not a simple task.

Could Microsoft have done it, since they took their own good time to bring out VPC7? No doubt. But I don't think it's in Microsoft's interest to make VPC as good as it could be.

I am pretty sure MS could make VPC run up to one third of the host system's speed if they really wanted to, and the dual G5 CPU's could make it even faster in certain cases. But that would mean that VPC, running on a 2,5GHz dual G5, would be the equivalent of a 700MHz PC, which would be more than enough for almost all Microsoft applications such as Access, Money, VS.Net, Project etc. It would provide Apple with good PR and be a good way for enterprise customers to migrate away from x86, where MS make almost all of its money.

I think this would be a golden opportunity for someone to work on a new emulator.

200% correct.

[Millennium]

In order for truly native graphics card support to work, Microsoft would have to pull off some rather impressive trickery on both the Windows side and the Mac (emulator) side. You'd have to sort of pseudo-emulate a graphics card inside VPC, except that all it would really do is call the real Mac card through OpenGL, CoreGraphics, and QuickDraw as appropriate (translating calls as needed). If done correctly, Windows (and even the Windows-side driver) would think that it's calling a graphics card. This would be the most compatible way to do things, at any rate.

Can this be done? Yes. It's been done before, in fact; that's what the 3dfx support from VPC3; the Windows-side Voodoo2 driver called pseudo-emulated Voodoo2 card in VPC3, which in turn called the real Voodoo2 card on the Mac. But times were very different then; 3dfx still existed as its own entity, AGP cards weren't popular yet, Glide was a viable 3D API, and we were drooling over Power Mac G3s running Mac OS 8.

Almost none of that code is any good anymore. It may make for an interesting point of reference, perhaps even useful at times. But new Macs haven't been able to run it for almost a year, so we can't expect any of that code to be usable for VPC7. They'll have to rewrite it from scratch, with only slightly more documentation this time than last time.

[kupan787]

Sorry if this is bad form, but here are some posts made in a thread over at AppleInsider about a year ago by Programmer:

Good software could fix it though. If Microsoft decided to (for whatever reason) they could implement a native PowerPC/OpenGL driver for the DirectX Windows subsystem and performance would improve very very dramatically.

And then this was in response to someone saying they talked with a guy at Connectix saying it was basicly not posssible:

They can't do it because they don't have the balls (or resourcing) to write native drivers. An OS has drivers to insulate it from the hardware, and those drivers aren't part of the OS. By implementing a special trap in their emulator to jump to PowerPC code (simple to do) that would enable them to selectively "supplement" the hardware drivers that Windows comes with. These new drivers would, when called, drop into native PowerPC code and do the work more quickly, possibly using native MacOS X services (e.g. OpenGL) to do so.

VPC took the approach of purely emulating the hardware and thus using the Microsoft drivers (written in x86) to pretend to use the fake hardware that they fake using PowerPC. This is very inefficient, but it allowed them to make it at least as stable as Windows running on the real hardware they chose to emulate. With a bit more work they could improve performance tremendously. This has been done before so the fact that the VPC guys say it can't be done is just a cop-out.

Ah, but most of the x86 to PPC translation is in some portion of Windows -- usually the graphics (especially in the case of 3D). If you eliminate the need to translate this then your overall emulation will go considerably faster.

I had a discussion with the Connectix guys about this years ago as well, and the upshot was that they simply chose not to implement this kind of punch through in their emulator. Its not that they can't, its that they don't have the will to do so (probably due to the poor investment / revenue ratio). Their system works by emulating hardware. Fine. Invent a new fake piece of hardware, write the PowerPC emulator for the hardware, and then write a x86 driver for it that is paper thin and just invokes fake hardware functionality to do the work. You're "emulating" a piece of hardware that doesn't actually exist. Ta da, you've got a PowerPC driver.

Hardware companies write new drivers all the time and they don't have the luxury of redefining the hardware's interface to match exactly what they need it to be. In six (seven?) versions of VPC Connectix hasn't done this, even though it is probably less technically challenging that their x86 emulator itself. And you don't need to modify the Windows OS itself, that's why it has drivers! Most of the time is spent in the grapics calls of the driver so it would have a significant speed improvement -- especially for 3D and video decoding. Sorry, this is just Connectix being cheap-ass about it.

[Wiskedjak]

Originally posted by alphasubzero949:
Now should this surprise anyone?

Typical of M$.

How is it typical of M$? Do you honestly think M$ cares if you're running Windows on an Apple or a Dell?

[Angus_D]

Originally posted by goMac:
No, it doesn't intercept the Win32 drawing calls, it intercepts the graphics cards drawing calls that are sent to the GPU. VPC does not rasterize once on a virtual GPU in VPC and then send it out to the Mac OS where it is rasterized again along with the Mac OS windowing system, it simply rasterizes right to most likely a GWorld.

So basically it's emulating a graphics card.

[RonnieoftheRose]

I thought I explained everything but here's a simplified blow by blow

Motherboard. The chipset being emulated is the HX/FX chip set. This is being emulated by the Mac's CPU. It has no support for AGP but proper code can allow Windows in VPC to communicate with PCI devices. For that to happen both Windows and Mac drivers have to be installed. This is why Voodoo PCI companion cards worked in VPC3. Support for that was dropped in VPC4.

S3 Virge. This was the successor to the S3 Trio 64. It is a graphics card, not a motherboard chipset. It has nothing to do with VPC. It doesn't appear in the device driver list.

S3 Trio 32/64. This is the graphics card emulated "by the Mac's CPU" in VPC. There are no calls being sent to and fro to your Mac's graphic card. Everything you see being rendered in VPC's working window is work being done by your G3/G4/G5.

BX chipset. This was the first Intel chipset to support AGP. To get any graphics acceleration in VPC the whole app would have to be rewritten to emulate a BX or later motherboard. As with VPC3, Windows and Mac drivers would have to be installed for your host system's graphic card. MS would also have to emulate the AGP port in VPC.

It's that simple.

[goMac]

Originally posted by RonnieoftheRose:
I thought I explained everything but here's a simplified blow by blow

Motherboard. The chipset being emulated is the HX/FX chip set. This is being emulated by the Mac's CPU. It has no support for AGP but proper code can allow Windows in VPC to communicate with PCI devices. For that to happen both Windows and Mac drivers have to be installed. This is why Voodoo PCI companion cards worked in VPC3. Support for that was dropped in VPC4.

S3 Virge. This was the successor to the S3 Trio 64. It is a graphics card, not a motherboard chipset. It has nothing to do with VPC. It doesn't appear in the device driver list.

S3 Trio 32/64. This is the graphics card emulated "by the Mac's CPU" in VPC. There are no calls being sent to and fro to your Mac's graphic card. Everything you see being rendered in VPC's working window is work being done by your G3/G4/G5.

BX chipset. This was the first Intel chipset to support AGP. To get any graphics acceleration in VPC the whole app would have to be rewritten to emulate a BX or later motherboard. As with VPC3, Windows and Mac drivers would have to be installed for your host system's graphic card. MS would also have to emulate the AGP port in VPC.

It's that simple.

Ronnie... While it may emulate a graphics card... The GPU is not emulated. It's just spewing the 2D data right into a GWorld. Thats why the bridge to the GPU doesn't matter.

[RonnieoftheRose]

Originally posted by goMac:
Ronnie... While it may emulate a graphics card... The GPU is not emulated. It's just spewing the 2D data right into a GWorld. Thats why the bridge to the GPU doesn't matter.

Can you read English? I haven't mentioned a GPU. GPU's only came about when T&L was introduced on graphic cards. The S3 Trio 32/64 is NOT a GPU. It is a graphics chip but doesn't come under the GPU category. However it IS being emulated by the host system's CPU. Everything in VPC is. If you can't understand that everyone should leave you in fantasyland.

[goMac]

Originally posted by RonnieoftheRose:
Can you read English? I haven't mentioned a GPU. GPU's only came about when T&L was introduced on graphic cards. The S3 Trio 32/64 is NOT a GPU. It is a graphics chip but doesn't come under the GPU category. However it IS being emulated by the host system's CPU. Everything in VPC is. If you can't understand that everyone should leave you in fantasyland.

You're not making your point. My point is it's possible to forward things to the built in OS graphics drivers meaning you don't have to have Windows directly access your graphics card. You said that this was impossible because of something about raw PCI data. I'm saying raw pci data isn't an issue. Anything that displays anything on a screen must have some sort of processor that rasterizes the image for the screen (as you called it a "graphics chip"). This is a GPU. Textures and Lighting != GPU. That is a 3D co-processor. A 3D co-processor is a kind of GPU, but a GPU is not necessarily a 3D co-processor. Virtual PC does not rasterize the image, send it to the Mac OS, which un-rasterizes it and re-rasterizes it again as you're are saying. Instead, when the virtual GPU is instructed the "draw a red pixel here" it is sent into a Mac OS gWorld where it is rasterized once by Mac OS. Using a similar technique VPC could open an OpenGL graphics context in Mac OS X, forward OpenGL commands into the OS X context, and rasterize the OpenGL context using the Mac OS real hardware. As I've said before, the problem with DirectX commands received by the GPU is that the Mac OS does not support DirectX, so these must be translated to OpenGL on the fly.

[RonnieoftheRose]

Originally posted by goMac:
You're not making your point. My point is it's possible to forward things to the built in OS graphics drivers meaning you don't have to have Windows directly access your graphics card. You said that this was impossible because of something about raw PCI data. I'm saying raw pci data isn't an issue.

OMFG I didn't even come close to saying that. OMFG! OMFG! Beats his head against the wall and dies.........

[goMac]

Originally posted by RonnieoftheRose:
OMFG I didn't even come close to saying that. OMFG! OMFG! Beats his head against the wall and dies.........

Originally posted by RonnieoftheRose:
This won't be possible emulating an old chipset that doesn't support AGP. You can't pass anything from Windows to the Mac and back if the chipset being emulated is pre-AGP. Impossible. Impossible. Impossible. Repeat that until it gets through to your head. Built in OS drivers for graphics? On what? An HX/FX chipset? The Windows drivers won't see any graphics hardware in VPC running on your Mac is the mobo chipset is older than AGP.

Like I am saying, the bus has nothing to do with hardware graphics acceleration. Windows doesn't have to see your actual card.

Maybe you should figure out exactly what your point is...

[RonnieoftheRose]

Originally posted by goMac:
Windows doesn't have to see your actual card.

I'm going to buy a beanie bag. Anyone to recommend me the best one?

[Millennium]

Originally posted by kupan787:
Sorry if this is bad form, but here are some posts made in a thread over at AppleInsider about a year ago by Programmer:

And then this was in response to someone saying they talked with a guy at Connectix saying it was basicly not posssible:

About half of what this guy says is correct. The other half is pure BS. Some highlights:

They can't do it because they don't have the balls (or resourcing) to write native drivers. An OS has drivers to insulate it from the hardware, and those drivers aren't part of the OS. By implementing a special trap in their emulator to jump to PowerPC code (simple to do) that would enable them to selectively "supplement" the hardware drivers that Windows comes with. These new drivers would, when called, drop into native PowerPC code and do the work more quickly, possibly using native MacOS X services (e.g. OpenGL) to do so.

This isn't just incorrect, it's outright insane.

Switching back and forth between emulated and non-emulated code using two very different ABIs (not to be confused with APIs; an ABI deals with how the actual binary is stored on disk and loaded into memory) in the same driver borders on technical impossibility. You'd have to write special assemblers, compilers, and debuggers just for the emulator, and only then could you even think about writing drivers, which would themselves be an absolute nightmare to debug, because you'd be in a catch-22 situation: you'd have to debug them in the emulated environment (nothing else can run them), but you can't debug that environment truly adequately until the drivers are in place.

That's not even dealing with the fundamental differences between the Wintel and Mac architectures. I won't go into matters of which is superior to the other, but I'll point out that there are some very good reasons why it's much easier to emulate x86 on PPC than the other way around.

VPC took the approach of purely emulating the hardware and thus using the Microsoft drivers (written in x86) to pretend to use the fake hardware that they fake using PowerPC. This is very inefficient, but it allowed them to make it at least as stable as Windows running on the real hardware they chose to emulate.

Correct. It's inefficient, but it's the most stable approach. This was back in the days before Win2K, and so the last thing VPC needed was added stability issues on top of what Windows offered.

Their system works by emulating hardware. Fine. Invent a new fake piece of hardware, write the PowerPC emulator for the hardware, and then write a x86 driver for it that is paper thin and just invokes fake hardware functionality to do the work. You're "emulating" a piece of hardware that doesn't actually exist. Ta da, you've got a PowerPC driver.

The guy doesn't understand one whit of what he's talking about here, but he's stumbled -accidentally, no doubt- onto the right answer nonetheless. The approach of "emulating" a video card which Windows then uses like any other is what Microsoft is going to have to do. What he doesn't understand is how much work that takes. Real graphics cards often spend months, even years, with every last design issue being hammered out. Doing that with a whole system is not a trivial task in the slightest.

[kupan787]

Originally posted by Millennium:
The guy doesn't understand one whit of what he's talking about here, but he's stumbled -accidentally, no doubt- onto the right answer nonetheless.

And this is why I thought it might be unfair to post this, as he cant defend himself here.

Programmer, on the AppleInsider forums, is a knowledgeable guy. He seems to know his stuff pretty well. So I would give him the benifit of the doubt on this one, and assume he did know what he was talking about, and didn't blindly come about the right answer. If the thread wasn't over a year old over there, I would have just posted a link, so the discussion could have carried on over there...

[arekkusu]

Originally posted by Millennium:
This isn't just incorrect, it's outright insane.

Speaking as a programmer who has worked on both graphics (lots) and emulation (a bit), I believe the highly technical term for what is being discussed here is "HLE". It's not insane.

Back to the point, M$ hasn't done it for VPC 7.0. End of story.

[Millennium]

Originally posted by arekkusu:
Speaking as a programmer who has worked on both graphics (lots) and emulation (a bit), I believe the highly technical term for what is being discussed here is "HLE". It's not insane.

I was under the impression that he wanted to embed PPC-native code into drivers on the Windows side of things. That is very much insane. Actual HLE is another matter, and the second post alludes strongly to this, but he seems to be suggesting it as an alternative to his original proposal.

[arekkusu]

Quote: By implementing a special trap in their emulator to jump to PowerPC code

Obviously this is PPC code executed on the host. == HLE.

No, that doesn't mean it's trivial to implement (particularly wrapping DX into calling the Mac's GL) but it's not insane. M$ certainly could implement it if they threw enough resources at it. Maybe in VPC 8?

[a holck]

About native 3dfx support in VPC3:

VPC only supported the old Voodoo "3d only" PCI processors from 3dfx. These were the ones that had a loop through cable from your 2d card for normal operation.
They would simply switch on and close for the 2d signal when activated by an application addressing it by using the 3dfx Glide API. (No direct x / open GL back then)
What VPC 3 could do was to communicate directly with the card by initializing it, and ONLY if the mac driver was not loaded so the Mac Os was not initializing it, and had no knowledge of it.
So you would actually have a dead card sitting in your machine when not using VPC.
Also I believe it was utilizing the simplicity of the Glide APIs direct hardware operation.

This would also only work under OS9 where applications had direct hardware address, as this would be needed for this to work.
So basically the virtual machine would open a DMA channel to the PCI slot for the emulated subsystem.

The reason for Connectix to drop voodoo support was commented by a connectix engineer in 2000:
"One of the challenges in emulating a Pentium processor is that Intel chips store multi-byte data in reverse order from the PowerPC. This difference in "endianness" must be taken into account when executing Pentium code. The PowerPC has a special mode which allows it to simulate �little endian� mode (the native mode of Intel-compatible processors). However, on PowerPC processors prior to the G3, this mode came at a high performance cost - especially when the data in memory was "misaligned" (i.e. not stored to memory locations that are divisible by the size of the data). The G3 and G4 processors removed these performance bottlenecks, allowing Connectix engineers to finally take advantage of this previously ignored feature."

"Virtual PC 4.0 also removes support for Voodoo 1 and Voodoo 2 video cards. As mentioned above, the new Pentium emulation core runs in the PowerPC's "little endian" mode. This mode is incompatible with Voodoo frame buffers, so it is no longer feasible to support Voodoo cards within the emulator."

[Angus_D]

Of course the G5s don't have little-endian mode, either.

[P]

As I see it, native graphics card support could be done in several ways:

1. Sending OpenGL commands directly to the OS X Open GL and translating Direct X commands to OpenGL.

It all comes down to translating between Direct X and Open GL. Today, every graphics card on Windows has in essence two 3D graphics drivers - one for Direct X and one for Open GL. I know that MS has been working from time to time on a universal Open GL to Direct X driver, so that all of Open GL could be transformed into Direct X, meaning that graphics card manufacturers would only have to write one driver. This has not been successful yet, other than as an abysmally slow proof-of-concept.

2. Implement Direct X on OS X. Then send Open GL and Direct X commands directly to their respective counterparts on OS X side.

MS and Apple could implement Direct X beside OpenGL on the Mac, like we had QuickDraw 3D beside OpenGL on OS 9. There was some discussion about doing this when the first box diagrams of OS X were presented - there was a suspicious looking box next to OpenGL with only a ? in it. It has not happened, and I doubt it will, but it's not impossible. It would take a lot of help from Apple though, as well as new graphics drivers from all graphics boards.

This would of course mean that the Direct X layer could be called directly form any OS X program, meaning much easier porting from Windows. I doubt it will happen, but it could be done.

3. Do a repeat of the 3dfx thing and let the Windows driver send commands directly to the Mac graphics board.

This would only work in full-screen, and maybe the graphics board would have to "reboot" when switching ( I don't know how the boards work exactly, but there might be some problems with the endian-ness). In this case, the Windows driver would have to be in a correct environment - there is no PCI edition of modern graphics cards, so you can't pretend that your Radeon 9600 is in a PCI slot of a pre-BX class motherboard. In this case, a major rewrite would be necessary, yes.

[RonnieoftheRose]

Rewriting VPC to do all that would be harder than porting XP to the Power PC. After all, NT 4.0 ran on Power PC and they still have the code for it laying around somewhere.

[goMac]

Originally posted by RonnieoftheRose:
Rewriting VPC to do all that would be harder than porting XP to the Power PC. After all, NT 4.0 ran on Power PC and they still have the code for it laying around somewhere.

Uhhhh... it would actually be a lot simpler.

Even if you ported Windows to the PPC it wouldn't do you much good because the programs are still x86.

DirectX wrappers for OpenGl already exist. The problem is the companies that make them are at odds with Microsoft. I'm assuming Microsoft is attempting to write their own.

Don't forget, porting XP to the Mac would mean writing all the drivers for Mac devices. Thats a lot of work. VPC keeps a layer of virtualization in place that allows them to create on strict set of devices that Windows talks to, and it keeps x86 compatibility.

[RonnieoftheRose]

Originally posted by goMac:
Uhhhh... it would actually be a lot simpler.

Even if you ported Windows to the PPC it wouldn't do you much good because the programs are still x86.

Don't forget, porting XP to the Mac would mean writing all the drivers for Mac devices.

Windows PPC programs would be easy for MS to port. As for other apps they would run native on OSX. who needs Windows versions of every app? Also, when NT ran on Alpha RISC CPUs there was a binary translator built into NT to emulate apps on the fly. That was back in 96!

Regarding drivers, very few would have to be written considering that the there is a limited range of hardware in Macs. Other devices can run and be used on OSX anyway. There's no need to run every device on Windows PPC the same way we don't use every device with VPC.

[goMac]

Originally posted by RonnieoftheRose:
Windows PPC programs would be easy for MS to port. As for other apps they would run native on OSX. who needs Windows versions of every app? Also, when NT ran on Alpha RISC CPUs there was a binary translator built into NT to emulate apps on the fly. That was back in 96!

Regarding drivers, very few would have to be written considering that the there is a limited range of hardware in Macs. Other devices can run and be used on OSX anyway. There's no need to run every device on Windows PPC the same way we don't use every device with VPC.

The problem is that while MS could port all their programs easily, a lot of games would not work. All of Microsoft's products are already on Mac pretty much anyway (namely Office). 3rd party products are the important ones, and if they won't be bothered with Mac OS X, they certainly won't be bothered with the smaller subset running Windows PPC. A lot of games additionally use x86 assembly as a speed boost.

The problem with Windows NT for the Alpha was that it did not support x86 drivers or x86 dll's. This is an extremely huge issue. This kills a lot of different programs. A lot of people had trouble even running Microsoft Office on the Alpha.

The problem with just writing new drivers for Windows is a lot of Apple hardware is locked up tight. The power management systems and the graphics cards are not standard parts. Every time Apple releases a new machine they have to release a new version of OS X. Because Apple hardware varies much more than x86 hardware (which is very standardized, much more than Apple hardware) keeping Windows running natively on PPC would be a huge task and not worth the effort. Macs never actually supported the PPC of NT 4 because they are far different than even generic PPC machines. Keeping Windows running under OS X saves a huge amount of headache.

Not to mention, Macs are on a completely different motherboard system from when NT 4 was on the PPC. NewWorld didn't exist then.

[RonnieoftheRose]

Originally posted by goMac:

Not to mention, Macs are on a completely different motherboard system from when NT 4 was on the PPC. NewWorld didn't exist then.

It was called Nubus, Mr. Gworld. Honestly, shut up for once. Reading your posts is like trying to paint an igloo.

[entrox]

Oh boy, I feel like I'm on Slashdot.

I'll just throw in a link to Darwine, which will give better performance in exchange for compatibility, should it ever get finished.

[P]

Originally posted by RonnieoftheRose:
Rewriting VPC to do all that would be harder than porting XP to the Power PC. After all, NT 4.0 ran on Power PC and they still have the code for it laying around somewhere.

I never suggested that they do all of it, but they would have t do one of them. Probably 3. And the Intel chipsets are fairly similar anyway, so rewriting for a BX wouldn't be all that.

Just having XP run on PPC is likely as easy as just recompiling it, same way that OS X can run on x86 if you recompile it. As has already been noted in this thread, you still need drivers for a lot of things to work, but just getting the thing to boot should be easy. In fact, I think that that's already been done as part of the Xbox 2 project.

[Person Man]

Originally posted by RonnieoftheRose:
It was called Nubus, Mr. Gworld. Honestly, shut up for once. Reading your posts is like trying to paint an igloo.

Actually, he DID mean "New World." He wasn't talking about the older, non-PCI NuBus machines.

He was talking about the "New World" architecture introduced with the very first iMac... where most of the ROM code was stored in a file on the hard drive.

But even then, NT for PPC would not run on the so-called "Old World" machines, AFAIK.

[goMac]

Originally posted by RonnieoftheRose:
It was called Nubus, Mr. Gworld. Honestly, shut up for once. Reading your posts is like trying to paint an igloo.

No, Ronnie. It's NewWorld, the motherboard design introduced with the first iMac (also called Columbus).

GWorld is a Carbon graphics world you open for drawing.

Before you start throwing insults, please go get informed. I'm starting to doubt your expertise in this considering I actually do OpenGL programming, and know what a NewWorld Mac is.