Transform Feedback (GL 3.0) questions

[DarkRaven]

During my work with transform feedback some questions arise, but I don't like to start new topic for each of them.. As sated, I'm talking about core 3.0 transform feedback, that should be equal to EXT_transform_feedback

1. Can we transform feedback arrays?
2. Can we transform feedback matrices?
3. Is it good idea to use GL 4.0 transform feedback versions? (ARB_transform_feedback2/3)
4. Is NV extension limited to NVIDIA hardware? for example (NV_transform_feedback)

Info:
I'm using NVIDIA hardware with most recent drivers
The context I'm using is v3.2 for GL and v1.5 for GLSL
I'm using transform feedback in separate mode

Further description:
1. NV extension for transform feedback states: "A valid name cannot be any portion of a single vector or matrix, but can be a single element of an array or the whole array." However I couldn't find anything like that for EXT that has been made core. I could feedback single array index e.g. "var[0]" without problem. Feedbacking whole array "var" resulted in INVALID_OPERATION on glBeginTransformFeedback, but no errors were generated when calling glTransformFeedbackVaryings. Also size returned by glGetTransformFeedbackVarying was correct - the size of array specified in shader. The problem is that any description of INVALID_OPERATION for Begin* does not correspond whit what I'm doing, and I'm 100% sure that it is generated by Begin*.

2. Same problem as first, but I couldn't find ANY way to feedback it because as stated by NV version - name shouldn't be a portion of vector nor matrix. Again INVALID_OPERATION on Begin*, calling glGetTransformFeedbackVarying resulted in correct resolution of varying type and no errors were generated while registering "matrix" for feedback.

3. There are several new TF versions in openGL 4.0. Currently I'm not interested in those as I'm targeting older hardware, but I find it strange. First of all why there should be more than one version? One uniform way to do thing would be much better. Is it possible that all of them become core, or just one should have this opportunity? It seems to me like a development stage when they're testing what is the best way to do it, but ARB_ are already aproved extensions and that's quite confusing then.

4. I couldn't find clear answer to this question, even though it is not necessarily limited to question of TF. I view NV extensions as experimental and as such, I don't think AMD would try to implement them. However, I might be wrong, so I'm asking for clarification.

Thanks

[Alfonse Reinheart]

A word of warning first:

Please stop trying to break your drivers. Please stop reading the spec and trying to find all of the dark corners that nobody uses.

That will only end in tears.

Use the API in the way that you know will work and there won't be problems. It doesn't matter what the spec says; if your driver says "no," then it won't work. Pretend that the GLSL spec says that arrays and matrices can't be outputs; just vectors and scalars.

Don't look for driver bugs and driver bugs won't find you.

1. Can we transform feedback arrays?
2. Can we transform feedback matrices?

It's always best to look at the actual spec for core behavior, not the extensions. According to GL 3.3:

When writing varying variables that are arrays, individual array elements are written in order. For multi-component varying variables or varying array elements, the individual components are written in order.

So it clearly states that writing such things are possible, and it states how writing them works. So you found a driver bug.

Stop looking for them.

There are several new TF versions in openGL 4.0. Currently I'm not interested in those as I'm targeting older hardware, but I find it strange. First of all why there should be more than one version?

They aren't "versions"; they're "more functionality". They just gave them numbers instead of stating more specifically what they do.

TF_2 is a combination of stuff. It has objects, pausing/resuming, and `glDrawTransformFeedback`. They could have made three inter-dependent extensions, but there was no point. Anything that could do one could do them all, and anything that couldn't do one couldn't do any of them.

TF_3 is similar, adding another bag of stuff. And again, anything that could do one could do all, and so forth.

More to the point, I don't know why they made it two extensions (instead of just one). But there it is.

Is NV extension limited to NVIDIA hardware? for example (NV_transform_feedback)

With a very few exceptions, if an extension is proprietary, it is only implemented by that vendor. The best way to answer any such questions is to use the OpenGL Extension Viewer.

[DarkRaven]

Please stop trying to break your drivers.

The problem is I'm writing universal wrapper for shader programs (Yeah maybe I'm crazy, but I hate using C syntax in C++ world. You can later take a look at it when I'm finished) and I like to debug my projects before releasing. So it's not really my call unless I don't block certain behavior - but before doing such thing, asking people with more experience won't hurt. Also I tend to be careful before yelling "Hey you got bug over there!", as I'm no OpenGL pro and the bug is more likely to be in my code but with this one I was out of options.

Anyway I'm like master of breaking drivers and finding limitations, so you can't really beat it out of me. GLSL >>implementations<< have really too much dark places that can possibly freeze whole computer (just try to make arrays too big and voila), but you can't blame me for exploiting them. Sometimes you need out of box thinking and sometimes it doesn't pay off, but I believe this and other forums are made to consult problems if they happen to appear.

[aqnuep]

Please stop trying to break your drivers. Please stop reading the spec and trying to find all of the dark corners that nobody uses.

That will only end in tears.

Use the API in the way that you know will work and there won't be problems. It doesn't matter what the spec says; if your driver says "no," then it won't work. Pretend that the GLSL spec says that arrays and matrices can't be outputs; just vectors and scalars.

Don't look for driver bugs and driver bugs won't find you.

I don't agree with you, Alfonse. Yes, do use the not-so-common paths and do try the corner cases, and in case you meet a driver bug then just report it. Otherwise we'll never have good drivers.

[DarkRaven]

Progress update:
2) Feedbacking a matrix is possible, however I managed to get it working only in interleaved mode. This is not so much of a trouble, because whit 'mat3' NVIDIA GLSL compiler already warns for separate attribs that

error: Varying (named var) contains more components than allowed by MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS.

This is somewhat interesting because I don't get such error whit 3 separate vec3 varyings. So it's definitely going to be driver bug as I believe they make binding location for each element of matrix resulting in 9 separate attribs, while my card is supporting maximum of 4. 'mat2' therefore doesn't generate compiler error but I don't supply buffers for used binding locations (and to be honest, I don't know which they should be, maybe the index of matrix varying name in 'glTransformFeedbackVaryings' function + offset inside matrix). Acording to specs, if an used binding location doesn't have valid buffer connected running the transform feedback will result in error, so that is what I observed.

Still, this is good for nothing as most of graphics cards don't support as much as 16 separate attribs only for feedbacking 'mat4' and result of such feedback would be wrong anyway. It is much better to break matrix into vectors and feedback those or use interleaved mode in which the matrix is fed back correctly with just specifying it's name for feedback.