On 07/12/15 18:12, Dylan Baker wrote:
On Mon, Dec 07, 2015 at 02:26:00PM +0000, Jose Fonseca wrote:
It's making many assumptions about the wflinfo which are not true.
So completely disable it as a workaround.
Though I wonder if there's really any merit in adding a depending on
wflinfo. IMO, if piglit cares for the advertised GL/GLSL versions, it
should have its own internally utility program to dump every thing needed.
Parsing output from external utilities is begging for trouble.
If you don't have wflinfo, it'll go on and run anyway.
Yes, that was the workaround I took for my test slaves.
> It's also
designed to be as conservative as possible with versions, and we should
absolutely try/except the float if a driver doesn't return a sane
version.
>
Out of curiosity what driver are you using, I tested this extensively
against both i965 and against RadionSI. I had no issues at all, when
anything failed it would simply fall back to running the test and
letting the binary skip itself, as it was designed to do.
It happened with all drivers I normally:
- On NVIDIA it crashes because version string is "4.4.0 ...", i.e.,
"major.minor.patch". I believe this is fine.
Traceback (most recent call last):
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/base.py", line
181, in execute
self.run()
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/base.py", line
234, in run
self.is_skip()
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/opengl.py", line
314, in is_skip
if (self.__info.gl_version is not None
File "/home/jfonseca/work/vmware/tests/piglit/framework/core.py",
line 204, in __get__
value = self.__func(instance)
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/opengl.py", line
182, in gl_version
raw.split('\n'), 'OpenGL version string').split()[3])
ValueError: invalid literal for float(): 4.4.0
$ wflinfo --platform glx --api gl --profile core
Waffle platform: glx
Waffle api: gl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro K1000M/PCIe/SSE2
OpenGL version string: 4.4.0 NVIDIA 355.11
OpenGL context flags: 0x0
- With Mesa Xlib libGL.so.1:
Traceback (most recent call last):
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/base.py", line
181, in execute
self.run()
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/base.py", line
234, in run
self.is_skip()
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/opengl.py", line
322, in is_skip
if (self.__info.gles_version is not None
File "/home/jfonseca/work/vmware/tests/piglit/framework/core.py",
line 204, in __get__
value = self.__func(instance)
File
"/home/jfonseca/work/vmware/tests/piglit/framework/test/opengl.py", line
214, in gles_version
raw.split('\n'), 'OpenGL version string').split()[5])
$ wflinfo --platform glx --api gles3
Waffle platform: glx
Waffle api: gles3
OpenGL vendor string: WFLINFO_GL_ERROR
OpenGL renderer string: WFLINFO_GL_ERROR
OpenGL version string: WFLINFO_GL_ERROR
Not sure why this happens. Anyway, my interest is GL + GLX, not so
much GLES.
FYI:
I asked Chad (who maintains waffle) before I started this, and he made
the assertion that wflinfo output was designed for parsing by external
utilities and was considered API stable.
Also, I would prefer to have some kind of bindings for wflinfo rather
than parsing the string output, the goal was to have JSON interface
(google also wanted this interface for other uses), but neither they nor
I have had time to send anything.
All our tests use Waffle/Glut/etc. I think we could have simple "dummy"
tests that dump the desired versions. I don't see the need for external
tools or complex bindings. By doing something different than our tests
do, we're risking creating contexts slightly differently, and end up
making wrong assumptions.
Jose
_______________________________________________
Piglit mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/piglit
