OpenCL Support Atop Gallium3D Is Here, Sort Of

[BlackStar]

In any case, this evidence tends to be in favor of having a non-restricted version string.

On the contrary, this proves why glGetInteger(GL_MAJOR) and glGetInteger(GL_MINOR) are superior to any solution involving string parsing.

These methods can be trivially supported in Mesa 7.6 without advertizing OpenGL 3.0. Nvidia and Ati binary drivers expose these methods even on 2.1 contexts - there's no reason why Mesa cannot do the same.

Edit: Digging around, I think this post is the root of the GL_VERSION issue. The first number in "1.4 (2.1 Mesa 7.0.1)" is the highest OpenGL version that can be officially supported under the current GLX implementation when using indirect rendering. Which means that I either hit a Mesa bug or was just plain lucky by only using supported methods.

Still, the whole confusion wouldn't even exist with glGetInteger(GL_[MAJOR|MINOR]).

[V!NCENT]

No more that the algorithm itself has to be of a parallel nature. For example there are many ways of calculating pi and some algorithms are of a serial nature others are of a parallel nature. You could get these algorithms running on a GPU, but the results maybe slower because the codes serial nature, if you switch to an algorithm that is parallel in nature you can have massive speed gains.

Or, of course, if you have to do a lot of independent serial calculations and like to do as much of them at the same time as possible... which is why OpenCL interests me.

[nhaehnle]

Edit: Digging around, I think this post is the root of the GL_VERSION issue. The first number in "1.4 (2.1 Mesa 7.0.1)" is the highest OpenGL version that can be officially supported under the current GLX implementation when using indirect rendering. Which means that I either hit a Mesa bug or was just plain lucky by only using supported methods.

Okay, that does make a lot of sense.

Still, the whole confusion wouldn't even exist with glGetInteger(GL_[MAJOR|MINOR]).

You do realize that when that is implemented, glGetInteger(GL_MAJOR|GL_MINOR) would return version 1.4 in the situation where the GL_VERSION string is "1.4 (2.1 ...)", right? You would get exactly what you get with atoi or GLEE-style parsing.

So yeah, it might be a little more convenient for application developers, but it wouldn't actually change anything.

[nanonyme]

Hmm, as in with the principle GL_MINOR=1, GL_MINOR=2, GL_MAJOR|GL_MINOR=3, then pull first part for 1, second part for 2, full version with?

[nhaehnle]

Hmm, as in with the principle GL_MINOR=1, GL_MINOR=2, GL_MAJOR|GL_MINOR=3, then pull first part for 1, second part for 2, full version with?

Huh?


(I need to write at least 10 characters, so yeah: can you elaborate? Because I totally didn't understand your post)

[nanonyme]

I guess mostly what I had in mind was eg OpenGL version 1.5.x, glGetVersion(GL_MAJOR) returns 1, glGetVersion(GL_MINOR) returns 5.x, glGetVersion(GL_MAJOR|GL_MINOR) returns 1.5.x (as in, bitwise or on 01(bin) and 10(bin) => 11(bin))
ps. This is useless.