Strange behavior from native OpenGL

[Roderick Colenbrander]

Hi Ken,

The problem you explain is indeed strange. I have never encountered this
issue with opengl32 before. I tried to find a bug in the test, but didn't
really see anything strange. If your theory about wglCreateContext being
needed to 'heat things up' is true, maybe it has to do with ICD loading.

Assuming you picked a pixel format, which requires the hw vendor's ICD, I
believe wglCreateContext kicks of driver initialization unless it is done
implicitly at an earlier stage (something happens for sure earlier for
pixel format enumeration). Various ICD provided functions like the ICD
version of wglGetProcAddress are loaded at time and I wouldn't be surprised
if that is also when they hook up the ICD versions of MakeCurrent,
CreateContext, SetPixelFormat, GetPixelFormat and others. Just a wild guess.

Thanks,
Roderick




On Wed, Feb 12, 2014 at 6:46 AM, Ken Thomases <ken at codeweavers.com> wrote:

> Hi,
>
> I have been working on refining a d3d9 test patch I recently submitted <
> http://source.winehq.org/patches/data/102263> and noticed a strange
> behavior when running on a real Windows machine.  I'm wondering if anybody
> is familiar with it or can check my reasoning.
>
> The strange behavior is that a failed call to wglCreateContext() must be
> done before SetPixelFormat() will work properly.  The call to
> wglCreateContext() has to fail because it can't succeed until
> SetPixelFormat() has been done.  And yet it still seems to be necessary.
>
> My test does the following sequence:
>
> CreateWindowA()
> GetDC()
> ChoosePixelFormat()
> SetPixelFormat()
> GetPixelFormat()
>
> This seems fairly simple, straightforward, and commonplace.  Although
> everything through the SetPixelFormat() indicates success, the
> GetPixelFormat() call still returns 0.  This causes the test to be skipped.
>  This happened on the testbot, but I assumed that was caused by the VM's
> display driver.  However, when I got the chance to try on a real Windows
> machine, it happened there, too.
>
> I looked around to see if the same sort of thing is done elsewhere in
> Wine.  It's done in the opengl32 tests in test_setpixelformat() <
> http://source.winehq.org/source/dlls/opengl32/tests/opengl.c#L254> and it
> works there, both on the testbot and the Windows machine.
>
> So, then I figured it must be working in those tests because of stuff that
> is done beforehand.  I disabled most of the opengl32 tests other than
> test_setpixelformat().  That was testbot job <
> https://newtestbot.winehq.org/JobDetails.pl?Key=4751> and it still passed
> on the testbot and real Windows.
>
> I then disabled the expected-to-fail call to wglCreateContext() that is
> done in the test main entry function (START_TEST(opengl)).  Once that is
> disabled, test_setpixelformat() starts failing in the same way as my d3d9
> test.  That is testbot job <
> https://newtestbot.winehq.org/JobDetails.pl?Key=4752>.
>
> So, can it really be that a failed call to wglCreateContext() is necessary
> before SetPixelFormat() will work properly?
>
> One thing that I haven't had the chance to test yet is whether a
> wglCreateContext() call _after_ SetPixelFormat() will cause a subsequent
> GetPixelFormat() to return the right format.  That is, perhaps
> SetPixelFormat() has worked and the pixel format is remembered, but it's
> only "realized" once wglCreateContext() is called.  And GetPixelFormat()
> only returns realized pixel formats.
>
> Also, it's possible that it's sufficient to call any opengl32 function and
> not wglCreateContext() specifically.  (ChoosePixelFormat(),
> SetPixelFormat(), and GetPixelFormat() are gdi32 functions.)
>
> In any case, that would mean that my d3d9 test will have to link with
> opengl32 and call one of its functions.
>
> -Ken
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140212/36aafc5b/attachment.html>