4 ms·
I am not a graphics card hardware expert, but I thought that the current tail end of the pipeline (shaders) basically was a massively parallel pixel handling en
by ethbro 11y ago
I am not a graphics card hardware expert, but I thought that the current tail end of the pipeline (shaders) basically was a massively parallel pixel handling engine. And that the hardware for that has been getting more and more generalized because of GPU compute.
Is it that inefficient to bend modern graphics card shaders to the task of rendering obscene numbers of pixels without the front end 3d geometry calculations?
- vanderZwan 11y agoNo, that's exactly what Kilgard's approach is about, and it's backwards compatible with any NVIDIA card that supports CUDA, I believe.
- moonchrome 11y agoProblem is GPUs are build for triangle rasterisation and that part is still baked in to hardware for performance. You can use hack stuff on top of the 3D pipeline to render vector graphics but you need to transform geometry and do triangulation which isn't really efficient and can't be done on the GPU efficiently. Coupled with overhead of talking to the GPU trough drivers and you end up being CPU bound and not a lot faster than the CPU rendering. The equation changes when you increase screen resolution as the cost of setting up GPU to render is determined by geometry not by resolution and GPU rasterization is practically free compared to CPU which gets slower as you increase the resolution - so at the high enough resolution the driver overhead might matter less.