Apparently they're "HardWare Schedulers"
AMD: Pirate Islands (R* 3** series) Speculation/Rumor Thread
- Thread starter iMacmatician
- Start date
-
- Tags
- amd
Apparently? Does someone here have seen the full presentation where this may be elaborated? And also how it works?
2 Hardware Schedulers and 4 new ACE's with 128 Queues Total?
New ACE F32 with 32 Threads, 4 ACE's = 128 Threads/Queues
http://image.slidesharecdn.com/gs-4...90x-one-big-dgpu-by-michael-mantor-18-638.jpg
New ACE F32 with 32 Threads, 4 ACE's = 128 Threads/Queues
http://image.slidesharecdn.com/gs-4...90x-one-big-dgpu-by-michael-mantor-18-638.jpg
The info comes from The Stilt at Muropaketti/MuroBBS, no idea where he gets his info from but seems to have legit and deep knowledge especially on AMD products (also has the CPU clock frequency world record, http://hwbot.org/submission/ 2615355 )
There is a HWS, or hardware scheduling mode mentioned for managing compute in the AMD HSA Linux kernel driver.
AMD might indicate whether that is coincidental at some point.
The naming similarity may point to it being a path where the hardware has more autonomy in how it receives commands or schedules work.
AMD might indicate whether that is coincidental at some point.
The naming similarity may point to it being a path where the hardware has more autonomy in how it receives commands or schedules work.
There is another difference - and i think that is what you're missing here:
With a heat pipe, you take the heat from one point of the card (usually from above the GPU where in case of the Nano the fan's hub would be as well) and transport it to another location in x/y coordinates (when looking straight at the card). With a Vapor Chamber, your main direction of heat transfer would be analogous to the z-axis, i.e. from one side of the VC to the other, in addition to a (less distinct) x/y spread compared to a heat pipe.
So, you transfer a certain amount of heat directly to where the sun don't shine... err... the air does not flow (as much). That's why on "traditional" cards with Vapor Chambers, there's a large set of fins soldered directly onto it and the (blower type) fan mounted next to the whole construct.
But since the alleged AMD slide double confirmed a Vapor Chamber, the discussion seems moot. It's only interesting, whether or not the cooling is sufficiently quiet.
Last edited:
D
Deleted member 2197
Guest
Is 0xAF now considered optimum for testing gaming performance?
You have to compromise at 4k. That's no surprise.
IMHO, no AF is a huge compromise and not one worth making. Something else has to go.
gamervivek
Regular
Indeed no AF is much worse than having one or two settings turned down from the 'ultra' preset which is rarely good enough to justify the performance loss.
Such comparisons like the Fury X vs. 980Ti slide only bring scorn upon AMD from those in the know.
Such comparisons like the Fury X vs. 980Ti slide only bring scorn upon AMD from those in the know.
I don't know the specifics of this, but 4K resolutions are putting the onus back on graphics horsepower and trade-offs for settings need to be maintained on many solutions. Like [H]'s reviewing principle the guide is to provide the settings that will attain "playable" (~30FPS) at 4K, likely with the primary in-game quality settings being chosen as the less favourable break-point than AA/AF settings. Peoples preference may differ, but you are getting into a more subjective range when you are looking to maintain a minimum playability bar; but this is far more interesting than debating graphs with all details set to the max at stupid 100+FPS's.
I'm not promoting anything, likewise I can't speak to everyone's preferences - the same goes for a benchmark lab and things would get even more muddy if you start disabling individual graphics settings. In the interest of keeping things normalised as much as possible and for the sake of time you are likely to look at the big buckets that are tweakable on every title - resolution, major game settings buckets (Normal, High, Ultra Quality, etc.) and AA/AF levels.
Same thing. HWS allows some ACEs to be "more equal than others" as Dave said.
The code operates in one of three modes, selectable via the sched_policy module
parameter :
- sched_policy=0 uses a hardware scheduler running in the MEC block within CP,
and allows oversubscription (more queues than HW slots)
- sched_policy=1 also uses HW scheduling but does not allow oversubscription, so
create_queue requests fail when we run out of HW slots
- sched_policy=2 does not use HW scheduling, so the driver manually assigns
queues to HW slots by programming registers
The "no HW scheduling" option is for debug & new hardware bringup only, so has
less test coverage than the other options. Default in the current code is "HW
scheduling without oversubscription" since that is where we have the most test
coverage but we expect to change the default to "HW scheduling with
oversubscription" after further testing. This effectively removes the HW limit
on the number of work queues available to applications.
http://lists.freedesktop.org/archives/dri-devel/2014-July/064011.html
Thank you for the information.
It felt like a small number of letters for an unintended name collision, but I couldn't cite anything to back up the assumption.
I do note that Sea Islands or the APU subset of it receives mention as the starting IP, to give context where HWS may fit in this thread.
It felt like a small number of letters for an unintended name collision, but I couldn't cite anything to back up the assumption.
I do note that Sea Islands or the APU subset of it receives mention as the starting IP, to give context where HWS may fit in this thread.
gamervivek
Regular
Interesting, the one recent review pointing out AF hit that I could find was HardOCP's Watch Dogs review where 290X had much greater performance loss than 780Ti which barely budged with 16xAF.
As for AMD hurting themselves, the other thing conspicuous by its absence was the lack of DSR vs. VSR showdown in various reviews considering they had a slide showing how VSR had negligible performance hit on Fury X. With its abysmal 1080p performance it could have been a saving grace but VSR was nowhere to be found. The funny thing being that nvidia came up with this idea of having a greater resolution on widespread 1080p resolution monitors while AMD had more to gain from it.
It was just the opposite, AFAIK.
At least for the 290X, it was the cause for people getting upset because it often did not reach that number, while Nvidia always specifies a minimum speed and a boost clock that isn't guaranteed.
Jawed
Legend
I think 290X muddied the water because the default BIOS switch was "quiet" mode, i.e. throttle clocks at the merest hint of work. Non-reference coolers were fine.
But I also think AMD changed things. After the original HD7970 (and pals), base clock disappeared and AMD only gives boost clock as you say.
Titan X with its reference cooler is basically as bad as a reference 290X in quiet mode (87 versus 85% respectively):
(from http://www.hardware.fr/articles/937-9/protocole-test.html ) There's a smaller set of results for 3840x2160, where Titan X gets worse.
But where's the fuss about the Titan X?
Original HD7970 doesn't throttle.
But I also think AMD changed things. After the original HD7970 (and pals), base clock disappeared and AMD only gives boost clock as you say.
Titan X with its reference cooler is basically as bad as a reference 290X in quiet mode (87 versus 85% respectively):
(from http://www.hardware.fr/articles/937-9/protocole-test.html ) There's a smaller set of results for 3840x2160, where Titan X gets worse.
But where's the fuss about the Titan X?
Original HD7970 doesn't throttle.
D