View Full Version : A hyperthreaded GPU?
I'm not that knowledgable about 3d Hardware or CPUs (you could probably tell from this post) but could anyone tell me what they see as the biggest problem is in developing a hyperthreaded GPU (in the same vein as Intel HyperThreaded CPUs) is?
I mean would finding a way of getting the GPUs to work cooperately be very difficult?
Or what would bandwidth be a bigger problem since it would be shared between both the GPUs?
Or is actually building a hyperthreaded GPU too expensive or too complicated?
With my limited knowledge, I would say, that it's too early for that. I mean, GPUs aren't advanced enough to really need that technology. HT was developed to improve situation with general purpose CPU, where at any given time large part of silicon is sitting idle. 3D accelerator is a device tailored and optimized for very specific tasks - almost without that "waste", and there's not much you could help with HyperThreading-like solutions. Maybe "morphing" logic (I believe it was shown in a machine called hypercomputer HAL; EDIT: Here's a bit more info about this concept: http://www.eet.com/at/news/OEG20020429S0016 ) and/or "clockless" architecture would help, but that's pure, made straight out of air, speculation.
Thanks for clearing that up for me PrzemKo. :)
As far as I know hyperthreading has nothing to do with graphics accelerators.
Hyperthreading is basically letting the cpu have some knowledge of threads and be able to let them execute parrallel on the same CPU.
There is no analogy to a thread on GPU's. A GPU doesn't use threads or anything alike. The thing which you might be referring to is parrallel processing, which is something - if I am not mistaken - 3dfx had implemented on it's gfx cards. If I am not even more mistaken, the next nvidia board nv30 is the first board which 3dfx engineers are working on at nvidia. And as such, possibly the first nvidia board which might incorporate 2 different GPU's.
The exact topic of parrallel processing on gfx cards is not within my knowledge, but I am quite sure hyperthreading is surely not even an option to implement on a gfx card.
Depending on how much you're willing to stretch the definition, it could be said that it's already done in GF3/4, and possibly in a lot of other T/L hardware too.
Hyperthreading is about jumping between tasks for each instruction. This reduces the hit for flushing the pipeline after a branch misprediction. It also reduces latencies for complex instructions. If the instruction has high throughput but high latency, the apparent latency for each thread will always be reduced with hyperthreading. If the instruction has low throughput and high latency, the apparent latency will be reduced as long as the other thread(s) aren't doing that instruction simultaneously.
The VS hardware in GF3/4 has ALUs that has high latency but high throughput, but the latency is hidden by operating on several vertices at once. If each run of the VS program on one vertex is concidered one thread, then it could be called hyperthreading, at least it solves a prolem in a similar way. It's of course a simplified version since all threads are running the same program, and maybe even with the program counter in sync.
I think I've read somewhere that even traditionally expensive operations like reciprocal is done in one cycle. To avoid needing a reciprocal unit with throughput 1 op/cycle, they could do a static calculation to get a time shift between the threads so that only one thread uses that unit at one time. As long as reciprocals are sparse, it shold be possible, and otherwise the driver could add "nop" instructions to make it possible. If this is done, and the threads are running "shifted in time" to each other, then it would be a rather close match for multithreading.
It's of course a simplified version since all threads are running the same program, and maybe even with the program counter in sync.
This is just a more precise informations; nVIDIA does use a different pc assigned to each thread. There are 3 program counters per vertex shaders pipe.
Dumb question: would a multithreading capable separate TCL processor be an option (at least technically) and what would the advantages/disadvantages of it be? (if possible of course)
Vertex processors are parallel or "multithreaded" by nature. Each pipe can operate on a different vertex.
Hyperthreading allows a general-purpose CPU to do two things in parallel.
A 3D core already does huge amount of schtuff in parallel.
Way back with Voodoo2 we had the first card with two TMU's - operating in parallel to do two texture layers in a single cycle.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.