Ilia Mirkin
Ilia Mirkin
To confirm the issue, the trace from https://bugs.freedesktop.org/show_bug.cgi?id=109371 decodes fine on x86 with the following patch: ``` diff --git a/lib/trace/trace_parser.cpp b/lib/trace/trace_parser.cpp index 73e287c8..7cf0b56d 100644 --- a/lib/trace/trace_parser.cpp +++ b/lib/trace/trace_parser.cpp @@ -26,6...
My G5 died. I won't be pursuing this anytime soon.
One additional problem is that the arguments to glCopyImageSubData go srcName, srcTarget, but the interpretation of srcName depends on srcTarget. This needs to be handled in a "post" visitor type...
Yeah, I discovered this when replaying a trace on nouveau that was recorded on i965, trying to figure out why glCopyImageSubData was failing with nonsensical errors. The glObjectLabel errors were...
In case someone else hits this before it's fixed for real, it's easy enough to hardcode it to always use e.g. the texture remapping table, like so: ``` diff --git...
Note that there's now a GL_EXT_blend_func_extended available in GLES2+, and is already supported by mesa. Not sure what the implications of GLAMOR on GLES2 are.
No, there are _gles2 versions available.
Mesa exposes NV_read_buffer/depth/stencil on GLES - I think Rob added those to enable apitrace to read those out.
Is there any chance this will ever get in? Should I just close it? Rebase it? I can't use `--sparse` without this patch, since the current logic ends up over-removing...
It's supported by some versions of nouveau...