I speak about time between first complains and first solution. Latency issue was unnoticed for months while the stuttering issue was revealed in a few days. That clearly shows, what was the more significant problem.
AMD: Sea Islands R1100 (8*** series) Speculation/ Rumour Thread
Ah, so it was only semi-confirmed! :sly:
Seriously, you gotta make sure its double confirmed guys
Dave did hint at a misunderstanding. But really, this just goes to show that, as I said then, AMD's communication blows big time.
UniversalTruth
Veteran
Ok, then we will see later this week. Looking forward. Hope it will be good news.
Last edited by a moderator:
Does your software stack expose it nowadays though (honest question)? I recall that for example Cypress hardware supported concurrent kernel execution, yet that was never exposed by the software.
OpenGL guy
Veteran
Yes. As I said, you can take advantage of async compute in OpenCL. We also support concurrent kernel execution when there are no dependencies between dispatches. These features are available on Southern Islands chips. I've requested that samples be written to demonstrate the features, but it's really easy to try for oneself. Also, SI supports two async compute queues, so you can even overlap execution that way as well. In OpenCL you just create two command queues and send dispatches to both queues, as long as there are no depencies, and hardware resources are available, then execution will overlap.
Foot, meet shotgun.Good marketing - they forced themself to release a clarification.
looking forward to it
http://www.pcworld.com/article/2027813/amd-promises-to-squash-confusion-and-quickly-clarify-2013-radeon-plans.html
In some contexts, having a stable product lineup is good, since it promises continued availability and support for things like corporate products--although I'm not sure of the appeal of the upper SKUs to that market.
I'm trying to guess a context for this sort of product where the spotty and tone-deaf messaging isn't a strip-tease of disappointment.
Maybe there's a better and optimized slide deck, and AMD uploaded the wrong version for download.
Goddamn this is painful to watch.
I'm trying to guess a context for this sort of product where the spotty and tone-deaf messaging isn't a strip-tease of disappointment.
Maybe there's a better and optimized slide deck, and AMD uploaded the wrong version for download.
Goddamn this is painful to watch.
The HD 8000 series is already out for notebooks, so it can't be that.
http://www.amd.com/us/products/desktop/graphics/8000/pages/8000-series.aspx#2
Anyway, we'll know what's going on soon enough, there are only 3 days left in "this week". In the meantime we'll just have to scratch our heads. I know AMD is supposed to have fired many of its PR/communication people, but still, WTF?
Is "two" a magic number here, or does it support "many" queues or a priority queue? If the former, does it just partition the GPU spatially, or can each core/compute unit thinger/whatever you want to call it pull from either queue when it needs work? Who decides the priorities/scheduling?
OpenGL guy
Veteran
Two is the limit for the async compute queues on SI. There is no partitioning at all: As long as resources are available, wavefronts will continue to be scheduled. I'm pretty sure that the graphics queue is "high priority", to make sure your desktop stays interactive as much as possible, but you still may have to wait until resources free up.
Ah ok, so if a task is blocked, it'll just go ahead and take one from the other queue? Does a single task block an entire queue then? Also seems somewhat dangerous if tasks can't be pre-empted... a long-running compute task could still disrupt the overall experience. Not that that's not the case on most/all GPUs, but seems like we need a better solution long term.
This has historically more or less been the case for all GPU tasks, graphics or otherwise. It's just that a traditional GPU usage means multiple tasks (draw calls) over the course of a 30 ms frame, so a "long-running" task was still quite short.
With the advent of GPGPU, and even just complex shaders with non-trivial control flow for that matter, having some way to terminate a shader program became quite important. Windows Vista introduced a watchdog timer in WDDM 1.0, which allowed the OS to forcibly terminate a hung shader program, which previously would froze the system and required a reboot iirc. Windows 8 brought in WDDM 1.2, which actually supports real preemptive multi-tasking (see DXGI_GRAPHICS_PREEMPTION_GRANULARITY).
OpenGL guy
Veteran
I think it's a limitation of the Windows scheduler that multiple applications can't have command buffers running in the same queue simultaneously. The GPU would be happy with it as long as it weren't backed up so that it couldn't fetch more commands, i.e. some blocking operation within the queue.
As mentioned above, there are new features in Windows 8, but they're not foolproof. The best way to avoid TDR (Timeout Detection and Recovery, aka the watchdog timer), is to make sure the command buffers you send to the GPU don't take longer than 2s to execute, at least until GPUs start supporting preemption.
Yeah I'm well aware of how GPUs work guys, I'm just curious about the GCN hardware details 
Incidentally these sorts of things is why WebGL is sort of hilarious to me... people really think there's suitable security sand-boxing all through the GPU software/hardware stack? Heh
Right, i.e. it can't preempt. Can GCN actually handle multiple simultaneous applications and maintain process and memory isolation though? IIRC DX Spec allows some weird stuff like out of bounds local memory writes to corrupt *any* local memory on the chip. Now I doubt with GCN OOB local memory writes can corrupt another "core"'s local memory, but it would definitely have to ensure things like separate processes can't be scheduled on the same "core", and technically would have to wipe the local memory in between context switches.
Incidentally these sorts of things is why WebGL is sort of hilarious to me... people really think there's suitable security sand-boxing all through the GPU software/hardware stack? Heh
The Tech Report: Fate of AMD's Sea Islands obscured in the fog
Good thing AMD bothered to clarify things, it's so much clearer now!
Here's my interpretation, or perhaps I should say exegesis: there will be new SKUs in the 7000 Series, based on new silicon, but not on a new architecture. I suppose they will be to Southern Islands what Richland is to Trinity: a whole bunch of minor bug fixes, design tweaks, and power-management improvements.
Then, come the end of the year, something really new. Maybe.
Good thing AMD bothered to clarify things, it's so much clearer now!
Here's my interpretation, or perhaps I should say exegesis: there will be new SKUs in the 7000 Series, based on new silicon, but not on a new architecture. I suppose they will be to Southern Islands what Richland is to Trinity: a whole bunch of minor bug fixes, design tweaks, and power-management improvements.
Then, come the end of the year, something really new. Maybe.
http://www.anandtech.com/show/6751/amd-reiterates-2013-gpu-plans-sea-islands-beyond
Enjoy your HD8000 rebrands I guess.
Enjoy your HD8000 rebrands I guess.
Last edited by a moderator:
Similar threads
