https://bugs.kde.org/show_bug.cgi?id=363124

Joe <m...@openmailbox.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m...@openmailbox.org

--- Comment #15 from Joe <m...@openmailbox.org> ---
Created attachment 103903
  --> https://bugs.kde.org/attachment.cgi?id=103903&action=edit
Patch -- QOpenGLFunctions_3_0 instead of GLES2 + WGL

I did some tests and it seems Linux is not affected by this bug.
For Nvidia it seems to break with driver 375.63+. (tested 368.81 - 378.49)
For AMD I couldn't find a driver it would run correctly. (tested 13.251,
15.200)
For Intel, this is my main computer running linux and I would rather not mess
with its configurations too much..
Unfortunately I don't have a mac so I couldn't do any testing for it.

I suspect the bug to be driver related and tried to debug wglgetProcAddress or
rather the ICD implementation DrvGetProcAddress (nvoglv64.dll) once I ruled out
invalid context, the possibility of wglMakeCurrent grabbing the wrong context,
init failure, ... It is rather strange that only glLogicOp and none of the sync
functions seem to be affected.
First I came to a different conclusion so some material I gathered as proof
become worthless but for some trivia, here some disassembly
(https://gist.github.com/Joefish/c300ebac0cb579334838927d8cad26ba)

The patch uses QOpenGLFunctions_3_0 to obtain an object pointer to supported GL
functions instead of GLES2 compatible QOpenGLFunction + extension loading.
According to Steam, Krita needs "Modern (since 2009) graphics / Intel HD" so
GL3.2 sounds like a reasonable target, even for macs (in my opinion). It would
also give a clear support target (instead of GLES2 + extensions), make many
checks obsolete and in this case also circumvent a bug by just getting an
offset table to the desired function subset. I think to remember than QPainter
depends on deprecated GL functions and that's why 3.2core can't be set by
default but Nimmy's opengl branch he already uses GL3.2Core (Core probably for
compatiblity with OSX) like commit dd32d5e421a4a357e268bd2dbb8b679b6ddd2699
So, according to KisOpenGL::setDefaultFormat 3.0 is fine and once the way is
free for 3.2 we can bump it up.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to