4 ms·
I do GPU driver development, and I love GPUs, but articles like this, which are extended statements of the form “GPUs are faster than CPUs” is just ignorant, or
by thechao 9y ago
I do GPU driver development, and I love GPUs, but articles like this, which are extended statements of the form “GPUs are faster than CPUs” is just ignorant, or a sales pitch. A lot of times I see this process:
1. CPU code is slow;
2. Port code to GPUs; it’s super-fast!
3. Backport low-cross-communication parallel codebase to CPU: it's even faster!
That is, the GPU port forces developers to think about fine- and large- scale threading granularity, and to design low-communication algorithms. However, having done this, the same algorithm runs better on the CPU than the GPU, because the GPU is starved of bandwidth.
- zeusk 9y ago/offtopic I'm interning with a GPU driver development team next summer but have no experience with Graphics programming or Shaders. I have some experience with university level OS course and a past internship where I worked on linux but not much else. Can you recommend some resources on GPU from the point of view of an operating system/driver programmer? I tried some of the AMD and Nvidia architecture sheets but were not basic enough for me to grasp and moreover they were oriented towards extracting performance from the respective architectures.
- thechao 9y agoThe only API facing GPU programming I’ve ever done is the first dozen-or-so of the NeHe tutorials back in 2003. And lots of single triangles & quads. I’ve written lots of software rasterizers. If you want to understand modern graphics HW, then try to write a fully programmable (shader based) software rasterizer in less than 500 loc of C/++. It’ll really bring to clarity the stages, what they do, and why they’re included. Hint: use function pointers for the shaders.