Falcosoft wrote:

Ok I have created a video about an Nx6325 with a resolution of 1024x768. The problem is the screen capture itself is quite taxing for this PC and I had to force it to a lower performance state
to demonstrate the issue (as I have described above). So the outcome on the video is much worse than in real life. But I had switched between Aero enabled/disabled states so the difference can be noticed. The point is at 1400x1050 the situation is worse and problem free Aero usage is only guaranteed if no p-state changes are allowed. Unfortunately I cannot get an NC6320 with Intel core duo and GMA 950 anymore. But at that time Aero was not fluent on them either.

But what are we looking at here exactly? You say you force it to a lower performance state, then you're surprised that performance is lower?
If the poor Aero performance is simply caused by power saving settings that are chosen too aggressively by the vendor (or in this case by yourself), how is that Vista's fault (because you admit that it is problem-free when power management is disabled? That pretty much proves that the GPU is capable of Aero, does it not)?
Also, this still doesn't prove that the GPU is the problem. There is a bottleneck, but you would need to do deeper investigation to see if it's the CPU or the GPU that is responsible for the performance issues.

All in all, I don't think it's a strong case 😀
It reminds me a bit of the era when 3D accelerators started implementing power saving modes, and some people suddenly discovered that if you ran legacy 2D benchmarks, that some new cards scored lower than old cards.
They would make all sorts of claims about how the drivers were broken, or things were not accelerated anymore and whatnot.
In reality, modern cards just clocked as far as possible to save as much power as possible. How far they clocked down was somewhat arbitrary, and depended on what the vendor still considered 'fine' performance in 2D mode. Which was obviously lower than some old high-end cards that ran flatout all the time.
In practice it was never an issue, and nobody would even have noticed the 'poor' 2D performance if it wasn't for those synthetic benchmarks.

Scali wrote:

But what are we looking at here exactly? You say you force it to a lower performance state, then you're surprised that performan […]
Show full quote

Falcosoft wrote:

Ok I have created a video about an Nx6325 with a resolution of 1024x768. The problem is the screen capture itself is quite taxing for this PC and I had to force it to a lower performance state
to demonstrate the issue (as I have described above). So the outcome on the video is much worse than in real life. But I had switched between Aero enabled/disabled states so the difference can be noticed. The point is at 1400x1050 the situation is worse and problem free Aero usage is only guaranteed if no p-state changes are allowed. Unfortunately I cannot get an NC6320 with Intel core duo and GMA 950 anymore. But at that time Aero was not fluent on them either.

But what are we looking at here exactly? You say you force it to a lower performance state, then you're surprised that performance is lower?
If the poor Aero performance is simply caused by power saving settings that are chosen too aggressively by the vendor (or in this case by yourself), how is that Vista's fault (because you admit that it is problem-free when power management is disabled? That pretty much proves that the GPU is capable of Aero, does it not)?
Also, this still doesn't prove that the GPU is the problem. There is a bottleneck, but you would need to do deeper investigation to see if it's the CPU or the GPU that is responsible for the performance issues.

On either front, it sounds like the Aero developers assumed they had more hardware capability to work with. A dual core Turion 64 isn't a weak processor, and it has a reasonably powerful integrated GPU onboard as well. Even downclocked, I would expect Vista to be able to use it for translation and blitting operations with good performance. Nobody wants the latest desktop GPU and a suitcase of batteries to run Aero on their laptop.

Hi,

But what are we looking at here exactly? You say you force it to a lower performance state, then you're surprised that performance is lower?

With Aero enabled the GUI performance is ruined to a level where it is disturbing. It only happens with Aero. XP and Vista/7 basic mode is not affected.

I never once used a system where I felt that the GUI was somehow slowing me down. And I always ran full Aero Glass.

Basically I have just claimed the following: Hey, I have met and used one...

how is that Vista's fault ?

I do not remember that I claimed it was Vista's fault. Instead I claimed:

So it can be concluded that on the notebook front many popular chipsets at that time were not quite Aero ready.

There is a bottleneck, but you would need to do deeper investigation to see if it's the CPU or the GPU that is responsible for the performance issues.

I have already investigated and written down what is the exact reason that caused this issue. I hoped you could find it. But If you happen to have missed it:

This was due to a special behavior of Turion64 (and all Athlon64) CPU's. Namely the memory clock was linked to the CPU core clock. So e.g. at 1600MHz that used CPU/5 divider the memory clock was 320MHz (DDR2-640). But under normal desktop usage scenarios the CPU switched to 800MHz power saving mode and so to 160Mhz (DDR2-320) memory clock. Without dedicated VRam the CPU and GPU had to shared this bandwidth. The reduced memory bandwidth under 1400x1500 (but even under 1024x768) made the experience awful under Aero.

Overall I have just wanted to point out that not all notebooks that were on paper Aero ready produced satisfactory GUI performance with Aero.
Be it architectural problem/too aggressive power saving or any other reasons you could meet the slow GUI phenomenon during everyday use.
Bye.

Scali wrote:

Yup, because there is little difference between the two technologically, as I said before. Things can go either way in these ben […]
Show full quote

95DosBox wrote:

But between the two 64-bit on DX10 the Vista SP2 DX11 beat the W7 SP1.

Yup, because there is little difference between the two technologically, as I said before.
Things can go either way in these benchmarks, the differences are very small, sometimes Vista is a smidge faster, other times, Windows 7 is.

95DosBox wrote:

A future DX9 tri test would probably still go to XP the way I have it set up. I can't see with the extra load/bloat from Vista and W7 to edge XP out.

It's not so much bloat as it is a completely different design.
In Vista, Microsoft completely redesigned the graphics driver, and moved a lot of processing out of the kernel-mode portion of the driver, and into user-mode.
As such, while Vista and later OSes still support DX9, the implementation is totally different, and is more of an 'emulation layer' on top of the new driver model that is aimed towards the DX10 API.
There may be slightly more overhead in DX9 in certain tests. In practice it is normally negligible though.
There are also other advantages: the drivers are now 'hogging' the system less in kernel-mode, meaning you get better cooperation between multiple threads/processes that use the GPU.
Of course, you will need specific types of benchmarks to see these differences. When doing benchmarks it is always important to understand what you want to measure, and how you can measure that.

95DosBox wrote:

But a lot of hardcore overclockers purposely install XP to max out benchmark performance. If XP really was worse I don't see why they go through all the trouble to get it to install and run it.

See above.
Perhaps in the overclockers-world, they value certain benchmarks that just happen to work best on XP for some reason. That doesn't say much about XP as a whole.
Or perhaps they just use XP because that is 'what they know'. It could well be that Windows 10 is actually faster, but nobody ever bothered to check, because they always benchmark with XP, and that's how they compare.

I could do some tests down the road on the same computer. It could in theory do a 98SE / 2K / XP / Vista / W7 / W10 (skipping 8.0 and 8.1) and do a full comparison. Crysis 1 would only qualify for XP to W10. It might be possible to backport it to 2K to work or it may work with tweaks. For the 98SE / 2K/ XP tests I will use another older game. I wonder if anyone is even curious about such a benchmark? Might be all for nothing in the end. 😀

I think the overclockers focus on the single core performance XP benchmark. That's just a guess. It could be good at multicore too if the benchmark program is coded to support multicore in XP. Most games for XP probably do single and dual core effectively.

Since you seems to know more about the internal differences between Vista and W7 graphics. Are you able to port W7 drivers to function properly on Vista? How about that XP classical user interface? Is there a way to transfer the Vista user interface Windows Classic Mode into Windows 7? Maybe some sort of Explorer swap?

Falcosoft wrote:

With Aero enabled the GUI performance is ruined to a level where it is disturbing. It only happens with Aero. XP and Vista/7 basic mode is not affected.

So what does that prove, other than that the power management settings have been poorly chosen?
I mean, Aero uses more GPU acceleration features than basic mode. So it will be hit harder by excessive throttling of eg VRAM bandwidth or shutting down shader units.
So the balance is different (likewise the actual power consumption would be different, they may not actually be saving as much power this way).
But as you yourself said, without power management, Aero works fine on that hardware, so I would blame AMD for having poor power management.

Falcosoft wrote:

So it can be concluded that on the notebook front many popular chipsets at that time were not quite Aero ready.

Yes, and I disagree with that, because 'Aero ready' means that the hardware is capable of running Aero properly. Which you admitted it does when power management is disabled. Ergo, the problem is in the implementation of power management on that machine. The system would be fast enough if it wasn't throttled too far.

Falcosoft wrote:

This was due to a special behavior of Turion64 (and all Athlon64) CPU's. Namely the memory clock was linked to the CPU core clock. So e.g. at 1600MHz that used CPU/5 divider the memory clock was 320MHz (DDR2-640). But under normal desktop usage scenarios the CPU switched to 800MHz power saving mode and so to 160Mhz (DDR2-320) memory clock. Without dedicated VRam the CPU and GPU had to shared this bandwidth. The reduced memory bandwidth under 1400x1500 (but even under 1024x768) made the experience awful under Aero.

Yes, so that's 100% AMD's fault then.
Perhaps they could even have solved that in the driver: boost memory speed a bit whenever there is Aero-functionality.

Falcosoft wrote:

Overall I have just wanted to point out that not all notebooks that were on paper Aero ready produced satisfactory GUI performance with Aero.

Yes, but in this thread people were blaming Vista/Aero for being too inefficient, when apparently the machines suffering problems have poorly designed/implemented power management.

You see, the thing about hardware acceleration is that hardware can do things faster than a CPU can. That's what usually makes it way more efficient. That is, a CPU would take way longer to perform window drawing operations in software than the GPU does in hardware, and may consume more power for longer periods of time doing so. The GPU needs less resources to do so. That's the idea that Aero is based on. And in most cases that is true, see here for example:
http://www.tomshardware.com/reviews/xp-vs-vista,1531-11.html

Windows Vista doesn't require more energy than Windows XP, whether running under full CPU load or idle. We also tried to stimulate the power consumption at the plug by aggressively moving windows or by switching between multiple tasks in 3D mode (Windows key + [Tab]). We would have expected an increased power draw, since Vista and its AeroGlass interface are more 3D-intensive and require 3D acceleration. However, there was no noticeable increase in power requirements due to the involvement of the 3D subsystem. This might be different with automated loads, but a single user cannot cause sufficient 3D load to influence the power draw.
...
There is good news as well: we did not find evidence that Windows Vista's new and fancy AeroGlass interface consumes more energy than Windows XP's 2D desktop. Although our measurements indicate a 1 W increase in power draw at the plug, this is too little of a difference to draw any conclusions. Obviously, the requirements for displaying all elements in 3D, rotating and moving them aren't enough to heat up graphics processors. This might also be a result of Windows Vista's more advanced implementation of ACPI 2.0 (and parts of 3.0), which allows the control of power of system components separately.

Scali wrote:

So what does that prove, other than that the power management settings have been poorly chosen? I mean, Aero uses more GPU accel […]
Show full quote

Falcosoft wrote:

With Aero enabled the GUI performance is ruined to a level where it is disturbing. It only happens with Aero. XP and Vista/7 basic mode is not affected.

So what does that prove, other than that the power management settings have been poorly chosen?
I mean, Aero uses more GPU acceleration features than basic mode. So it will be hit harder by excessive throttling of eg VRAM bandwidth or shutting down shader units.
So the balance is different (likewise the actual power consumption would be different, they may not actually be saving as much power this way).
But as you yourself said, without power management, Aero works fine on that hardware, so I would blame AMD for having poor power management.

There is another narrative where Aero uses too much VRAM bandwidth or shader power.

gdjacobs wrote:

There is another narrative where Aero uses too much VRAM bandwidth or shader power.

Which is demonstrably false.
I already said it: what Aero does in terms of '3D rendering' is much simpler than a regular 3D scene.
Assuming some basic level of functionality (ie SM2.x) means that the GPU can do a lot of things 'for free'. For a GPU, a 'regular' 2D blit is no cheaper than rendering textured triangles with texture filtering, since it's all deeply pipelined and optimized with special hardware circuitry.

The reason why whese GPUs can run these 3D scenes while they struggle with Aero was already explained: power management throttled performance too far in 2D mode, while in 3D they run the GPU flatout.
So it's not Aero being too slow or using too much bandwidth or shader power, it's the power management turning the memory and GPU down too far.

1. It's really the same statement. It just depends if you look upon performance being fixed and max throttling being a requirement or not.
2. The solution is to reduce requirements somehow, increase performance somehow, or a combination of both. If you're saying requirements can't be reduced, obviously performance must be increased. As you stated, power management can be adjusted or disabled, but this has negative implications for energy usage and battery life. For some, this is a problem.

gdjacobs wrote:

1. It's really the same statement. It just depends if you look upon performance being fixed and max throttling being a requirement or not.

No, because 'max throttling' is arbitrary. Microsoft has no control over what IHVs implement in terms of throttling, and as such there's no way this could be a requirement.
If AMD sold systems 'designed for Vista', yet throttling made them unable to handle Aero acceptably, then AMD simply screwed up.

gdjacobs wrote:

2. The solution is to reduce requirements somehow, increase performance somehow, or a combination of both. If you're saying requirements can't be reduced, obviously performance must be increased. As you stated, power management can be adjusted or disabled, but this has negative implications for energy usage and battery life. For some, this is a problem.

As demonstrated, Vista doesn't have worse power consumption than XP (which was tested on a machine that was not throttling to the extreme).
In fact, on certain hardware, Vista even has better battery life because of improved power management APIs in the driver model.
But nothing can save you from IHVs screwing up.

I don't care about comparing with XP. I care about how much power the GPU sucks in various power states. If Vista needs the GPU to operate in higher power states for the 2D desktop, the GPU will consume more energy. As you said, this may be worth it due to savings elsewhere. Furthermore, you can't call this a bug in power management as the SM2.0 IGPs from AMD were already out in consumer hardware when Vista went gold. It's a compatibility issue that went unresolved with culpability on both parties.

gdjacobs wrote:

If Vista needs the GPU to operate in higher power states for the 2D desktop, the GPU will consume more energy.

It was not the GPU that was the problem, it was the shared memory that was downclocked into oblivion. Which probably barely saved any watts at all, compared to the bandwidth you would require for acceptable Aero performance.
On the other hand, moving more of the rendering to the GPU may actually save power compared to the classic rendering model.

gdjacobs wrote:

As you said, this may be worth it due to savings elsewhere. Furthermore, you can't call this a bug in power management as the SM2.0 IGPs from AMD were already out in consumer hardware when Vista went gold. It's a compatibility issue that went unresolved with culpability on both parties.

I don't see how Microsoft would have any blame whatsoever.
AMD all the more: those IGPs didn't 'magically' work in Vista. They had to specifically write Vista-compatible drivers. As said, Vista uses an entirely different and incompatible driver model compared to XP.
So if AMD had to write a new Vista driver for the IGP anyway, they also had to implement power management in that driver. Which they screwed up.
Who also screwed up would be the OEMs that would have sold systems with this AMD hardware with Vista preinstalled and a 'Designed for Vista' logo on them.

If that's the case, it's likely the CPU is clocking down the HT frequency as well, as I believe memory clocks are a fixed divisor of the HT clock. The savings are likely beyond what's achieved by downclocking the DRAM chips, but also power savings in the IMC and HT hub.

As for responsibility, Microsoft definitely shares in that. They optimized Aero. They set performance requirements and specifications for the OS. They WHQL certified and signed the drivers. They also have tremendous influence with vendors.

gdjacobs wrote:

They set performance requirements and specifications for the OS.

They did, and nothing stops IHVs and OEMs from ignoring these and selling their hardware as 'Vista-compatible' anyway (if they even did that).

gdjacobs wrote:

They WHQL certified and signed the drivers.

They do, but WHQL is quite a well-defined test.
One of the things is that Microsoft only tests the 'default' configuration.
There are various examples of drivers that are WHQL-compliant in their default configuration, but would not pass WHQL if you change some settings in their control panel (such as various texture optimizations/cheats).
Likewise, the WHQL certification does most likely not include any aggressive power saving features. In fact, I wonder if they even test the case of the device not running on AC at all.

Aside from that, WHQL says nothing about performance.
It merely says something about a minimum level of compatibility of the hardware and driver.

gdjacobs wrote:

They also have tremendous influence with vendors.

Yea, so next you're going to blame Microsoft for AMD's Ryzen not working with v86 mode as well?
That's nonsense of course. Microsoft can't do anything about IHVs putting broken hardware on the market and installing Windows on them.

Scali wrote:

gdjacobs wrote:

They also have tremendous influence with vendors.

Yea, so next you're going to blame Microsoft for AMD's Ryzen not working with v86 mode as well?
That's nonsense of course. Microsoft can't do anything about IHVs putting broken hardware on the market and installing Windows on them.

First, I don't appreciate the straw man argument. AMD is absolutely to blame for the Ryzen bug, as it was with the first gen Phenom bug. This is demonstrably the case, as it wasn't just Windows that was impacted. In this case, AMD's SM2.0 onboard video hardware (RS690) was already designed, in production, and being released in consumer hardware prior to Vista's release. It successfully entered into power saving states and successfully extended batteries.

I'm not saying Microsoft is exclusively to blame for the problem, nor am I saying AMD or HP are either. I don't know the ultimate solution to this problem. I don't know if this is a blanket problem with all RS690 chipsets or just this one. Can the RS690 throttle more intermittently? Perhaps it could be patched over with a microcode or an ACPI table update. What I do know is that arriving at a solution to the problem would require cooperation amongst all three parties, all three parties have enough importance in the industry to initiate searching for a solution, and therefore all three parties share in the blame (such as it is).

gdjacobs wrote:

First, I don't appreciate the straw man argument.

It's not a straw man, it's a an appeal to ridicule, an analogy that is just as ridiculous as your argument.

gdjacobs wrote:

In this case, AMD's SM2.0 onboard video hardware (RS690) was already designed, in production, and being released in consumer hardware prior to Vista's release. It successfully entered into power saving states and successfully extended batteries.

Yes, so?
I really don't see how that has anything to do with anything.
There's a reason why Microsoft didn't just go out and give everyone the right to put a Vista-logo on their systems, and the whole thing about "Vista capable" ending up in a lawsuit, which people blamed on Intel's popular 915 not being "Vista capable", but Microsoft caving in to Intel pressure: https://arstechnica.com/gadgets/2008/03/the-v … icrosoft-bends/

Class action ultimately failed, because well: https://www.engadget.com/2009/02/19/vista-cap … atus-relevance/
Clearly it mainly says "Designed for XP", so people expecting a great Vista experience should have gone for the "Designed for Vista" machines instead.
I take it the AMD machines we're talking about here were of this category, so you get what you pay for (as you always do with AMD 'bargains' anyway).
My GM965 machine is "Designed for Vista" of course.

gdjacobs wrote:

I'm not saying Microsoft is exclusively to blame for the problem

You still haven't produced any good argument why Microsoft would be to blame in the first place. They write an OS. It's not their fault if other companies design shitty hardware and drivers and use that in combination with that OS.
It's clearly not the OS' fault, since this RS690 is an anomaly. Most other hardware works fine, better than XP. So the odds are in favour of Vista/Aero here.

Any OS has some minimum requirements. So the requirements of Vista are higher than its predecessors. So what? That's true of any version of Windows.
When NT came along, you suddenly needed a 386 as a minimum. Do you want to 'blame' that on Microsoft somehow? No, they design the OS for a certain purpose, and certain hardware requirements come with these design goals. I'm not sure why this is difficult to understand.
I mean, yes, Vista comes with an (optional) GPU-accelerated GUI that leverages shaders and texturing hardware. What's wrong with that?

gdjacobs wrote:

What I do know is that arriving at a solution to the problem would require cooperation amongst all three parties, all three parties have enough importance in the industry to initiate searching for a solution, and therefore all three parties share in the blame (such as it is).

Again, what can MS do?
They already designed an OS that can load third-party drivers, with a very advanced power management API, and Aero has tons of features for adjusting the look, feel and performance of the UI.
Everything you need is already provided by MS out-of-the-box. All you need to do is design good hardware, good drivers, and choose sane default settings for the systems you're selling.
Apparently the IHVs and OEMs failed there, presumably trying to leverage 'Vista compatibility' as a way to artificially inflate the value of the lousy hardware they were dumping. Some IHVs in particular think the driver department is an excellent place to cut costs.

Scali wrote:

It's not a straw man, it's a an appeal to ridicule, an analogy that is just as ridiculous as your argument.

Even if I agree that my point was ridiculous, you respond with this measured and rational retort?

Scali wrote:

Again, what can MS do? They already designed an OS that can load third-party drivers, with a very advanced power management API, […]
Show full quote

gdjacobs wrote:

What I do know is that arriving at a solution to the problem would require cooperation amongst all three parties, all three parties have enough importance in the industry to initiate searching for a solution, and therefore all three parties share in the blame (such as it is).

Again, what can MS do?
They already designed an OS that can load third-party drivers, with a very advanced power management API, and Aero has tons of features for adjusting the look, feel and performance of the UI.
Everything you need is already provided by MS out-of-the-box. All you need to do is design good hardware, good drivers, and choose sane default settings for the systems you're selling.
Apparently the IHVs and OEMs failed there, presumably trying to leverage 'Vista compatibility' as a way to artificially inflate the value of the lousy hardware they were dumping. Some IHVs in particular think the driver department is an excellent place to cut costs.

Nothing you've said absolves them from responsibility for compatibility problems. They imposed a change in the render model which evidently had usability implications for this existing hardware platform. I agree that it was for a good purpose, but it was their choice and the consequences therefore partly their responsibility. They have in depth knowledge on the design and implementation of Aero as well as the power management subsystem. Of course creating a solution would involve Microsoft, the depth of their involvement likely dependent on the complexity of the fix.

Microsoft are the centerpiece of the PC software industry and they carry weight with partners like AMD and HP. Intel has the market presence and capital to weather friction with Microsoft. That is not the case with AMD. Threatening to withdraw Vista Capable certification from certain models or chipsets because of performance issues, for example, would surely get managers scrambling. Alternately, they didn't notice or didn't care, in which case they should share in the blame for the oversight (for what little the blame is worth).

gdjacobs wrote:

Nothing you've said absolves them from responsibility for compatibility problems.

There is no compatibility problem. There is a performance problem. A performance problem which manifests itself only in certain power saving modes on certain hardware.

gdjacobs wrote:

They imposed a change in the render model which evidently had usability implications for this existing hardware platform.

That's the whole point: It's a new OS, its primary use-case is for being pre-installed on *new* hardware, existing hardware platforms are not its target.
For existing hardware, either you use the OS it was designed for (XP), or use Vista at your own peril.

gdjacobs wrote:

but it was their choice and the consequences therefore partly their responsibility.

Again, it wasn't a change, it was an addition. Firstly, you can configure Aero to various levels, to best suit your needs and your GPU's capabilities. Secondly, you don't even have to use Aero, there's still the classic mode to fall back on (which was the point about the Intel 915 chipset: it did not meet the minimum requirements for Aero, and as such you could only run Vista without Aero, which made the 'Vista Capable'-part so debatable).

Do you understand the words I have written above? Where is MS' resposibility here? As I already said in my previous post (which you apparently didn't read or did not understand), MS offers you the tools.

Heck, the GM965+Core2 Duo laptop I have is probably even slower than the RS690+Turion64 ones. But it has sensible drivers.
In fact, is this even a problem? I see this: https://www.techpowerup.com/reviews/AMD/690_Chipset/3.html

The AMD 690 chipsets are fully Vista certified, with drivers being available today. The integrated graphics can run the new Aero interface without problems. In the Vista Premium Compliance Test, even a Turion 64 platform in single channel mode can score well over the 1600 points required for Vista Premium certification.

gdjacobs wrote:

They have in depth knowledge on the design and implementation of Aero as well as the power management subsystem. Of course creating a solution would involve Microsoft, the depth of their involvement likely dependent on the complexity of the fix.

Poppycock.
I hate this widespread and naive view that so many people have that Microsoft writes most of the drivers for Windows (just because it works like that in the linux world doesn't mean it's like that everywhere, or that it's even a viable option).
The whole point of Windows and its modular driver model is that the IHVs write their own drivers, using the Driver Development Kit from Microsoft.
Microsoft has neither the resources nor the intention to write drivers for hardware. The IHVs know best how their hardware works. The OS-side is relatively simple, because MS has made nice APIs that abstract most complexity away. So any IHV could write a decent driver, in theory.
Of course if the hardware itself is broken, then no driver can help that.
Microsoft also can't help IHVs making stupid decisions in power management profiles and such. That's hardware-specific, and has nothing to do with the OS.

gdjacobs wrote:

Threatening to withdraw Vista Capable certification from certain models or chipsets because of performance issues, for example, would surely get managers scrambling.

This 'problem' you have been debating about so much is not a problem for most people. They either just accept that the performance is sub-par (they know that's what you can get when you buy hardware on a shoestring budget), or they simply either adjust the power management settings, turn down some Aero features, or switch to classic mode (technically 'Vista capable' means you shouldn't expect anything other than classic mode anyway, so the Vista capable sticker was already Microsoft's way of signaling that it's not really a good Vista machine. You didn't get the 'Designed for Vista' label).

Scali wrote:

There is no compatibility problem. There is a performance problem. A performance problem which manifests itself only in certain power saving modes on certain hardware.

I was thinking of it as a compatibility problem with AMD's power management scheme, but I think that's minor semantics.

Scali wrote:

gdjacobs wrote:

They imposed a change in the render model which evidently had usability implications for this existing hardware platform.

That's the whole point: It's a new OS, its primary use-case is for being pre-installed on *new* hardware, existing hardware platforms are not its target.
For existing hardware, either you use the OS it was designed for (XP), or use Vista at your own peril.

I would agree with you if OEMs and institutional customers with their own support teams were the only people who bought Windows. Even outside of support contracts and tier one vendor relationships, Microsoft does provide some limited support for their users. As long as it's not too expensive, it's probably worth it from a public relations standpoint.

Scali wrote:

gdjacobs wrote:

but it was their choice and the consequences therefore partly their responsibility.

Again, it wasn't a change, it was an addition. Firstly, you can configure Aero to various levels, to best suit your needs and your GPU's capabilities. Secondly, you don't even have to use Aero, there's still the classic mode to fall back on (which was the point about the Intel 915 chipset: it did not meet the minimum requirements for Aero, and as such you could only run Vista without Aero, which made the 'Vista Capable'-part so debatable).

Do you understand the words I have written above? Where is MS' resposibility here? As I already said in my previous post (which you apparently didn't read or did not understand), MS offers you the tools.

I understand what you're saying and don't disagree. Even prepackaged drivers in Windows are supplied by the IHV unless they're completely generic.

Let me rephrase the situation more clearly for you. Their application, a user interface and display subsystem called Aero, requires hardware such as what is provided by the RS690 chipset, but an issue with power management on that chipset causes performance problems when some laptops with the chipset installed enter power save mode.

If this were a game title, office application, paint program, CAD program, etc, etc, etc, a solution would almost certainly feature participation from the application developers. First, because it's in their interest to keep the user base happy and the application performant. Second, because they're most knowledgeable of what's going on with their own software. Lastly, because it's possible a fix is easiest and cleanest to implement on the application side.

I suppose it's also possible MS pressured AMD or HP to fix this problem and neither followed through, but that still wouldn't preclude publishing information on MSDN or similar on how to reduce Aero's GPU demand.

Scali wrote:

Heck, the GM965+Core2 Duo laptop I have is probably even slower than the RS690+Turion64 ones. But it has sensible drivers. In fa […]
Show full quote

Heck, the GM965+Core2 Duo laptop I have is probably even slower than the RS690+Turion64 ones. But it has sensible drivers.
In fact, is this even a problem? I see this: https://www.techpowerup.com/reviews/AMD/690_Chipset/3.html

The AMD 690 chipsets are fully Vista certified, with drivers being available today. The integrated graphics can run the new Aero interface without problems. In the Vista Premium Compliance Test, even a Turion 64 platform in single channel mode can score well over the 1600 points required for Vista Premium certification.

I'm not even convinced it's a driver issue so much as a difference in memory architecture which causes the problem.

gdjacobs wrote:

They have in depth knowledge on the design and implementation of Aero as well as the power management subsystem. Of course creating a solution would involve Microsoft, the depth of their involvement likely dependent on the complexity of the fix.

Poppycock.
I hate this widespread and naive view that so many people have that Microsoft writes most of the drivers for Windows (just because it works like that in the linux world doesn't mean it's like that everywhere, or that it's even a viable option).
The whole point of Windows and its modular driver model is that the IHVs write their own drivers, using the Driver Development Kit from Microsoft.
Microsoft has neither the resources nor the intention to write drivers for hardware. The IHVs know best how their hardware works. The OS-side is relatively simple, because MS has made nice APIs that abstract most complexity away. So any IHV could write a decent driver, in theory.
Of course if the hardware itself is broken, then no driver can help that.
Microsoft also can't help IHVs making stupid decisions in power management profiles and such. That's hardware-specific, and has nothing to do with the OS.

Agreed, Microsoft shouldn't be in the business of writing hardware drivers. Neither should game developers. That doesn't mean they have no business contributing to fixing problems that might arise with their applications running on someone else's hardware.

It's like saying sailors have no business with the way ships are built.

Scali wrote:

gdjacobs wrote:

Threatening to withdraw Vista Capable certification from certain models or chipsets because of performance issues, for example, would surely get managers scrambling.

This 'problem' you have been debating about so much is not a problem for most people. They either just accept that the performance is sub-par (they know that's what you can get when you buy hardware on a shoestring budget), or they simply either adjust the power management settings, turn down some Aero features, or switch to classic mode (technically 'Vista capable' means you shouldn't expect anything other than classic mode anyway, so the Vista capable sticker was already Microsoft's way of signaling that it's not really a good Vista machine. You didn't get the 'Designed for Vista' label).

In fact, I intimated this point earlier. The problem might not have been of enough consequence to bother fixing. And that's fine.

However, if the OEM, IHV, and application developer collectively make the decision to not fix a problem, they also own the consequences of their actions.

gdjacobs wrote:

I was thinking of it as a compatibility problem with AMD's power management scheme, but I think that's minor semantics.

But there isn't.
There's nothing 'incompatible'. AMD just turns down the clockspeeds so far that the system becomes sluggish.
The OS has no control over this, as I already said. The OS merely facilitates power management. How the hardware does that exactly, which components can be downclocked, turned off or otherwise managed, and to what degree, and what effect this may or may not have on the user experience, is completely outside of the control of the OS.
The OS merely provides the user with some sliders to apply certain levels of power management, in various scenarios (eg plugged-in and battery-powered).
If an IHV, OEM or user wants to shoot themselves in the foot with that, then they can. Heck, some people may actually *want* it that way, have you ever thought about that? It's not up to MS to decide what you can and cannot do with these power settings. Perhaps some people WANT to turn the power management up to the maximum, because they use their machines in ways we haven't even thought of yet (as in, not using the GUI at all, or at least not enough to be bothered by the performance).

I personally would be fundamentally against MS putting limits on this sort of thing.

gdjacobs wrote:

I would agree with you if OEMs and institutional customers with their own support teams were the only people who bought Windows. Even outside of support contracts and tier one vendor relationships, Microsoft does provide some limited support for their users. As long as it's not too expensive, it's probably worth it from a public relations standpoint.

But what do you disagree with then? MS indeed offers support to people who buy a retail version of Vista to upgrade their older PCs.
But it's still at their own peril. If they use hardware that is not 'Designed for Vista', Microsoft is not obliged to 'make it work'. They 'made it work' on all hardware that is 'Designed for Vista', so it is relatively easy for end-users to find out whether or not it is a good idea to upgrade to Vista.

For example, in my case, I was still using an old Terratec EWX24/96 sound card. I knew that was going to be a problem when upgrading to Vista x64 (in fact, it wasn't even supported in XP, but in XP I could still load the 2k driver at my own peril, for x64 there was no hope).
So when I upgraded, I simply bought a new audio interface to take care of that, paying attention to make sure I got one that had Vista x64 support.
Are you saying I should just have demanded that MS pay for my audio interface, because I had to upgrade it in order to use it with Vista x64?
It doesn't work that way.
You get support for *supported hardware*, nothing more.

In the case of power management, if you were to call MS support, you would likely just be advised to change the system settings, as mentioned before. There's nothing more MS can do. AMD is the one that could do more about it: remove nonsensical power settings from the driver.
But they won't do that, because their hardware was already considerably more powerhungry than Intel's mobile solutions. In fact, that's probably the reason why they chose those super-aggressive settings in the first place: to appear more competitive with Intel in the mobile market.

gdjacobs wrote:

Let me rephrase the situation more clearly for you. Their application, a user interface and display subsystem called Aero, requires hardware such as what is provided by the RS690 chipset, but an issue with power management on that chipset causes performance problems when some laptops with the chipset installed enter power save mode.

If this were a game title, office application, paint program, CAD program, etc, etc, etc, a solution would almost certainly feature participation from the application developers. First, because it's in their interest to keep the user base happy and the application performant. Second, because they're most knowledgeable of what's going on with their own software. Lastly, because it's possible a fix is easiest and cleanest to implement on the application side.

But that does not apply here, as I said a million times already: AMD simply chose nonsensical settings in their driver. There is nothing 'broken' in the first place.

gdjacobs wrote:

I suppose it's also possible MS pressured AMD or HP to fix this problem and neither followed through, but that still wouldn't preclude publishing information on MSDN or similar on how to reduce Aero's GPU demand.

MS already took care of that:
1) Vista includes a system test which gives you index numbers on how various components in your system perform. This also includes Aero performance
2) Based on these tests, Vista gives you recommendations, which include upgrading your GPU and turning down the visual options in the GUI.

In fact, Intel's installer always re-runs this test (WinSAT) after each installation of the video driver, and based on the results, it decides whether or not Aero will be enabled on your PC (there's a checkbox in the installer to skip this part).
Question is: why didn't AMD provide such a solution?

gdjacobs wrote:

I'm not even convinced it's a driver issue so much as a difference in memory architecture which causes the problem.

It's always a driver issue.
I don't think there's a 'difference in memory architecture', since the GM965 also has a dual channel controller, shared by the CPU and GPU, and I don't think it can change the clockspeed based on which of the two components accesses it either. In fact, I don't think any APU with shared memory is capable of this. It pretty much breaks the idea of shared memory: you'd have to dedicate a pool of memory to either the CPU or GPU in order to run that pool at a specific speed. That's just not how shared memory works. The memory pool is dynamically sized based on the GPU demands.

It's the driver that chooses when to change the clockspeeds, and by how much. So it was AMD's driver that decided to turn the power savings up to 11.

gdjacobs wrote:

Agreed, Microsoft shouldn't be in the business of writing hardware drivers. Neither should game developers. That doesn't mean they have no business contributing to fixing problems that might arise with their applications running on someone else's hardware.

It's a deliberate choice made by AMD, which can be overridden by the user. End of story.

Scali wrote:

You still haven't produced any good argument why Microsoft would be to blame in the first place. They write an OS. It's not their fault if other companies design shitty hardware and drivers and use that in combination with that OS.

Well, in many cases it is, in part, their fault - since they design the driver model, they provide the APIs for the driver designers, the implementation guidelines, and the back-end (most of which is closed-source). If there are bugs in the API, or if the documentation is lacking - part of the blame is naturally on Microsoft, and, yes, I've seen such situations. That is not to say anything about the specific case you're discussing here, of course. Just to point out that you cannot always absolve Microsoft of all blame if it's "driver-related".

Scali wrote:

I hate this widespread and naive view that so many people have that Microsoft writes most of the drivers for Windows (just because it works like that in the linux world doesn't mean it's like that everywhere, or that it's even a viable option).

I didn't quite understand what you were replying to (who said that Microsoft writes most of the drivers for Windows?), and I am not sure I understand what you meant about the Linux world. What "works like that in the Linux world"? Microsoft writes all the hardware drivers for Linux? 🤣 "Linux" writes all the drivers? Who is "Linux"? Either I didn't get your statement, or you don't understand how things work "in the Linux world".

Scali wrote:

The OS-side is relatively simple, because MS has made nice APIs that abstract most complexity away. So any IHV could write a decent driver, in theory.
Of course if the hardware itself is broken, then no driver can help that.
Microsoft also can't help IHVs making stupid decisions in power management profiles and such. That's hardware-specific, and has nothing to do with the OS.

I find it curious it how you live in the world where IHV hire shitty engineers that make broken hardware, and crappy coders that write bad drivers, but obviously on the OS side, all the APIs are "nice" and "relatively simple" and obviously Microsoft's own coders never have any bugs in their code. Or if they do - well, it's because the stupid IHV engineer didn't use it correctly, right? Never mind that documentation is often obscure/unavailable until it's too late.

I'd say you over-glorify Microsoft just a tad.