Computeshaders vs transformfeedback
category: code [glöplog]
Hi,
I've been doing some experiments using transform feedback and compute shaders in the recent version of Opengl (4.3 or something).
The shaders are almost the same - they are heavy, but not too heavy. Transform feedback gives me 65fps+ while the compute shaders top at 25fps.
I'm very surprised by this. My card is a 6870 AMD. Has anyone seen this before? I've checked for any obvious errors, but I can see none.
I've been doing some experiments using transform feedback and compute shaders in the recent version of Opengl (4.3 or something).
The shaders are almost the same - they are heavy, but not too heavy. Transform feedback gives me 65fps+ while the compute shaders top at 25fps.
I'm very surprised by this. My card is a 6870 AMD. Has anyone seen this before? I've checked for any obvious errors, but I can see none.
I'm looking forward to your next AMD-only demo!
Navis: What type of shader is the best depends entirely on the task they are performing. Yes, I've seen massive performance drops from using the wrong type of shader for the task.
the task is a simple particle engine with a feedback update on a single pos (xyzw). This is without any rendering, just the feedback loop.
I wonder if it is still better to stick to compute shader (less performance but easier to setup - also maybe better support across various cards) or go with transform feedback - with which I had some problems in the past.
I wonder if it is still better to stick to compute shader (less performance but easier to setup - also maybe better support across various cards) or go with transform feedback - with which I had some problems in the past.
id have expected you would be seeing the opposite - so maybe this is a driver issue?
Maybe you did choose some of the parameters for the compute shader (dispatch) in a "bad way". Work group size? Total number of threads? Register usage? Maybe the wrong "buffer/texture" type for the job? Bad placement of "memory barriers"?
Without seeing the particular code - no chance, just wild speculation. I guess almost everyone coding for GPUs these days has seen some interesting behavior under wild circumstances (and among other things I'm currently running into at least one new shader compiler bug per week, yay).
But, from what you described, I second smash. I would also go for compute.
I'm not really sure how good the current AMD OpenGL implementation is - maybe you also want to test your stuff on a current NVIDIA card, with current drivers.
Without seeing the particular code - no chance, just wild speculation. I guess almost everyone coding for GPUs these days has seen some interesting behavior under wild circumstances (and among other things I'm currently running into at least one new shader compiler bug per week, yay).
But, from what you described, I second smash. I would also go for compute.
I'm not really sure how good the current AMD OpenGL implementation is - maybe you also want to test your stuff on a current NVIDIA card, with current drivers.
The memory barriers and everything seems to be in good order. The total number of threads is set to total/16, total/16, 1 with total around 1m.
I will update drivers and test once again, would I be wrong to believe that , in general, compute shaders would now be supported better (across nvidia/amd) than the feedback transform?
I will update drivers and test once again, would I be wrong to believe that , in general, compute shaders would now be supported better (across nvidia/amd) than the feedback transform?
I don't think so. Support for Transform Feedback should be OK on both platforms, it's quite old already.
Maybe this could be interesting (it's a bit older...).
Maybe this could be interesting (it's a bit older...).
Navis: I presume you're either using buffer variables or images to output data from CS, and I'd assume these to be more expensive than any data captured directly from VS via TF.
If you had capture data from Geometry Shaders or - woe betide! - Tess Shaders, it would have been even worse ;)
If you had capture data from Geometry Shaders or - woe betide! - Tess Shaders, it would have been even worse ;)
We are entering the land of wild speculation.
Did both (around 2012/2013). No problems whatsoever. Well, it was not super fast, but still real-time.
Quote:
If you had capture data from Geometry Shaders or - woe betide! - Tess Shaders, it would have been even worse ;)
Did both (around 2012/2013). No problems whatsoever. Well, it was not super fast, but still real-time.
Okay that "no problems" part might not be entirely true ;) - you had to be careful, very careful.
A rule of a thumb, as far as performance of GS and Tess Shaders goes, is that the performance is strictly correlated with the generation of hardware you're using. The older, the more excruciatingly depressing the performance is.
However, if we restrict ourselves to hardware that has been released after these features made their way into the specs, well that's when things get funny.
However, if we restrict ourselves to hardware that has been released after these features made their way into the specs, well that's when things get funny.
well fuck me...
upgrading the catalysts to version 14 (latest, I had 13+) now gives me 120fps, up from 25.
I seriously need to punish these shaders and intimidate them with more perlin octaves, more curly noises, more more more...
upgrading the catalysts to version 14 (latest, I had 13+) now gives me 120fps, up from 25.
I seriously need to punish these shaders and intimidate them with more perlin octaves, more curly noises, more more more...
That's good and interesting at the same time, since if I were you I'd like to know what exactly set the older driver on fire. Eliminating that potentially "virtual" bottleneck in your own code may lead to a clue. Or not :)
Normal people upgrade and move along.
Normal people upgrade and move along.
(saying that there's a remote chance it's still "your fault" in a way but new drivers give more leeway or "allow" it through other factors)
by the way the feedbacktransform pipeline doesn't seem to work any more with the 14 - could be my fault. Having said that, I checked many online sources etc. and it is really not rocket science anyway to get either of these to work. (although you need to be a bit of a masochist in general).
Says the man who fully hardcodes his demos :)
Driver solutions from both camps are a blessing and manna from heaven, such programming!
Navis: You're experiencing exactly the same thing I experienced just before ragequitting AMD and buying an nVidia GPU. What you're still missing are driver crashes while gDEBugging.
Isn't it just grate when everything just works™?
Isn't it just grate when everything just works™?
Navis: Transform Feedback must work if the drivers call themselves conformant to the OpenGL standard. Now, I'm not sure which TF functionality version you're specifically talking about, but I'd suggest patching the relevant code snippets through to the AMD's dev team.
Please get in touch, if you need a hand with this.
Please get in touch, if you need a hand with this.
"Oh, hey, I'm having this interesting problem with your driver." - "Which blockbuster game are you working on?" - "None -- see, there's this small computer art scene called the demosc..." - *click*
Aivo koodaa :) Tarviikko tessetoida elämäänsä...
Yritin sanoo Petelle, et jos pikkunen gzen easter eggys, mut ei prkl:D
Yritin sanoo Petelle, et jos pikkunen gzen easter eggys, mut ei prkl:D
Good luck with AMD dev support! They might fix one thing, but then fuck something fundamental up in the process...