Originally posted by M@GOid
View Post
Announcement
Collapse
No announcement yet.
Intel Enables Tessellation Shader Support In Open-Source Linux Driver
Collapse
X
-
Originally posted by ultimA View Post
Not necessarily. Tesselation trades memory bandwidth for GPU compute resources. So if your application+hardware combination was bandwidth limited and was not fully utilizing the GPU otherwise, tesselation can improve performance by having to send less vertices to the GPU while still retaining the same quality.
Games seem to just use tessellation to add additional vertices on top of the old ones, providing a higher level of quality (for more gpu work).
Comment
-
Intel figured out how to fix the gpu crashes on gen7 hardware, and there are patches enabling it there now too.
Last edited by smitty3268; 25 December 2015, 05:12 AM.
Comment
-
Originally posted by smitty3268 View PostIntel figured out how to fix the gpu crashes on gen7 hardware, and there are patches enabling it there now too.
Unigine Heaven doesn't render correctly on ivy bridge, but you can see tessellation works:
It looks black without tessellation too. And yes, ~/.driconf is up to date, and with radeonsi it works fine in the same configuration.
By the way: Is intel ging to do something about X getting sluggish with heavy OpenGL loads? Running unigine heaven on my ivy bridge gpu not only makes X less responsive, it also makes the mouse pointer sluggish and jumpy...
Comment
-
Originally posted by ultimA View Post
Not necessarily. Tesselation trades memory bandwidth for GPU compute resources. So if your application+hardware combination was bandwidth limited and was not fully utilizing the GPU otherwise, tesselation can improve performance by having to send less vertices to the GPU while still retaining the same quality.
Using that additional geometry to then send less total vertices to the GPU, I don't consider being just tessellation itself but an advanced rendering technique that makes use of it. But the point is, with statically generated geometry, you only upload it once, whereas with tessellation, that shader stage will run on each draw call, unless of course you capture the generated vertices back into buffers and plain-draw them from there on, something that apparently is often done with geometry shaders (I don't know if it's actually viable with tess, especially since you often want varying level-of-detail as you walk through the 3D world).
It really all depends on what the application doing.
Comment
-
Originally posted by smitty3268 View Post
That presumes you are using tessellation to replace your old code that was providing identical vertices the old way. From what I've seen, that has never really happened in real apps. Maybe on mobile?
Games seem to just use tessellation to add additional vertices on top of the old ones, providing a higher level of quality (for more gpu work).
- Likes 1
Comment
-
Originally posted by siavashserverLess vertex shader work. When dealing with animated (skinned) geometries, usually 4 bone/joint transformations per vertex should be read from video memory and blended together. By using tessellation, the time consuming work will be done only for key vertices by vertex shader, and then extra level of detail will be simply added on top during tessellation stage.
I'm not sure I understand this scenario fully. Since the vertex shader runs after the tess ones, and on every vertex that was generated by tess, how do you save on expensive vert shader invocations? Or are you talking about running a non-tess pipeline on the few vertices first, capturing that via transform feedback, and then running it through tess with a simpler vert shader at the end?
Comment
-
Originally posted by siavashserverNo, the vertex shader runs before tessellation stage:
Comment
Comment