pyopengl-users

[PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Marcel P. <pfe...@fr...>]

Hi,

I've got a piece of code that runs flawlessly on Linux and Intel GMA HD
graphics:

http://pastebin.com/GcxAXBk7

Unfortunately with nearly the same software configuration and an ATI
Radeon 5770 using fglrx driver it refuses to run:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Traceback (most recent call last):
  File
"misc/shadertest120_triangle.py",
line 217, in <module> t.run() File
"misc/shadertest120_triangle.py",
line 203, in run self.init() File
"misc/shadertest120_triangle.py",
line 49, in init self.createShaders() File
"misc/shadertest120_triangle.py",
line 146, in createShaders glUseProgram(self.programId) File
"/usr/lib/python3.3/site-packages/OpenGL/platform/baseplatform.py",
line 379, in __call__ return self( *args, **named ) File
"/usr/lib/python3.3/site-packages/OpenGL/error.py", line 208, in
glCheckError baseOperation = baseOperation, OpenGL.error.GLError:
GLError( err = 1282,
	description = b'invalid operation',
	baseOperation = glUseProgram,
	cArguments = (3,)
)
~~~~~~~~~~~~~~~~~~~~~~~~~~~

glGetProgramInfoLog yields after linking:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vertex shader(s) failed to link, fragment shader(s) failed to link.
Vertex link error: INVALID_OPERATION.
ERROR: 1:1: error(#132) Syntax error: "v" parse error
ERROR: error(#273) 1 compilation errors.  No code generated

fragment link error: INVALID_OPERATION.
ERROR: 1:1: error(#132) Syntax error: "v" parse error
ERROR: error(#273) 1 compilation errors.  No code generated
~~~~~~~~~~~~~~~~~~~~~~~~~~~

First I'd like to know if I missed anything codewise and if it runs for
anyone else.

My configuration:
* Archlinux 64bit
* Python 3.3
* python3-opengl 3.0.2
* python-pygame-hg 3149-1

GL_SHADING_LANGUAGE_VERSION:  '4.20'
GL_VERSION:  '4.2.11978 Compatibility Profile Context'

Thanks if you have a look at it.

Have a nice evening,
Marcel

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Ian M. <geo...@gm...>]

Hey,

I had exactly this same problem some years ago. The solution for me was to
replace:
glShaderSource(self.fragmentShaderId, self.fragmentShader120)
. . . with:
glShaderSource(self.fragmentShaderId, [self.fragmentShader120])

Do the same for the vertex program.

Ian

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Mike C. F. <mcf...@vr...>]

On 13-01-14 05:44 PM, Ian Mallett wrote:
> Hey,
>
> I had exactly this same problem some years ago. The solution for me 
> was to replace:
> glShaderSource(self.fragmentShaderId, self.fragmentShader120)
> . . . with:
> glShaderSource(self.fragmentShaderId, [self.fragmentShader120])
Weird, I thought I'd fixed that ages ago.  The wrapper is *supposed* to 
look at the source and say "is this a string or unicode? then wrap it 
with a list"...

Maybe I dreamed I fixed it... ah... the low-level wrapper would only 
convert 8-bit strings into arrays-of-objects, any chance these were 
unicode strings?  The higher-level wrapper 
(OpenGL.GL.shaders.compileShader) *does* do the conversions for Unicode, 
but the low-level stuff was checking just for bytes.

Anyway, wrapping with a list should be fine, as it's what the API 
actually expects.

Thanks for pointing out the error,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Tomasz W. <ko...@gm...>]

Hello,

On 15 January 2013 15:51, Mike C. Fletcher <mcf...@vr...> wrote:
> Anyway, wrapping with a list should be fine, as it's what the API
> actually expects.

Just a little point- Wouldn't a .linesplit() on the string be more
suitable than wrapping with a single-element list?

Regards,
-- Kos
http://kos.gd

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Mike C. F. <mcf...@vr...>]

On 13-01-15 11:57 AM, Tomasz Wesołowski wrote:
> Hello,
>
> On 15 January 2013 15:51, Mike C. Fletcher <mcf...@vr...> wrote:
>> Anyway, wrapping with a list should be fine, as it's what the API
>> actually expects.
> Just a little point- Wouldn't a .linesplit() on the string be more
> suitable than wrapping with a single-element list?

My understanding is that implementations are free to parse each element 
within the set as a separate set of statements, while some 
implementations decide to concat the whole and then parse it.  Thus some 
implementations (Intel) will accept a shader which is passed as a string 
(which gets turned into N single-character strings), while others (ATI) 
demand that each fragment be a valid set of statements in GLSL.

That said, I can't readily point to a spec saying that's how it is 
*supposed* to work, that just seems to be how it works in reality. The 
shader fragments are null-terminated, not line-terminated, so there's no 
reason I can see to use \n as a splitting character, and I'd rather not 
introduce any arbitrary changes there.  Particularly thinking of things 
like this:

matrix = [
     ...
];

which would, I'm guessing, blow up on any of the finicky implementations 
if we did line-by-line splits.

HTH,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Tomasz W. <ko...@gm...>]

On 15 January 2013 18:21, Mike C. Fletcher <mcf...@vr...> wrote:
> My understanding is that implementations are free to parse each element
> within the set as a separate set of statements, while some
> implementations decide to concat the whole and then parse it.  Thus some
> implementations (Intel) will accept a shader which is passed as a string
> (which gets turned into N single-character strings), while others (ATI)
> demand that each fragment be a valid set of statements in GLSL.

Hmm. I have written a script to check that and I confirm that AMD is
also okay with keeping statements (or even tokens) span through
several shader strings.

I remembered that supplying source lines as separate shader strings is
useful because the lines end up being displayed in compilation error
messages - an important trait if you want good diagnostics.
Interestingly, that's not exactly the case now. On AMD the syntax looks like...

    Separate strings:
    ERROR: 4:1: error(#143) Undeclared identifier: three
    One string:
    ERROR: 0:5: error(#143) Undeclared identifier: three

So the error location appears to be in format "A:B", where A is
zero-based string index and B is one-based line number in a given
string (w/r/t newline characters in it).
If this kind of behaviour is consistent across drivers, then indeed
there's no benefit at all to splitting source into lines.

Additionally, I also haven't found any reference at all to semantic
meaning of "shader strings" as accepted by glShaderSource, or
specifically to their relation to lines of code.

Please go ahead and tinker with my code here:
https://gist.github.com/4540890 . I'm very interested how Nvidia and
Intel format the error locations.

Regards,
-- Kos

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Mike C. F. <mcf...@vr...>]

On 13-01-15 01:43 PM, Tomasz Wesołowski wrote:
> On 15 January 2013 18:21, Mike C. Fletcher <mcf...@vr...> wrote:
>> My understanding is that implementations are free to parse each element
>> within the set as a separate set of statements, while some
>> implementations decide to concat the whole and then parse it.  Thus some
>> implementations (Intel) will accept a shader which is passed as a string
>> (which gets turned into N single-character strings), while others (ATI)
>> demand that each fragment be a valid set of statements in GLSL.
> Hmm. I have written a script to check that and I confirm that AMD is
> also okay with keeping statements (or even tokens) span through
> several shader strings.
You seem to be correct that the strings are working if they are split, 
even within a single token (i.e. that the parser is (loosely speaking) 
concat-ing the strings before parsing)... which begs the question of why 
the single character strings weren't working. Weird.

I don't actually have any machines with Nvidia or Intel, so I'm afraid I 
can't help with that testing.

I do like the idea of the independent test context decorator, so I've 
added one to the pyopengl/tests directory (using raw Pygame).

Enjoy,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com