Bug 110921 - virgl on OpenGL 3.3 host regressed to OpenGL 2.1
Summary: virgl on OpenGL 3.3 host regressed to OpenGL 2.1
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL: https://gitlab.freedesktop.org/mesa/m...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-14 14:39 UTC by Andrew Randrianasulu
Modified: 2019-06-25 11:15 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
glxinfo from guest (76.28 KB, text/x-log)
2019-06-14 14:39 UTC, Andrew Randrianasulu
Details
glxinfo from host (llvmpipe) (47.92 KB, text/plain)
2019-06-14 14:43 UTC, Andrew Randrianasulu
Details
glxinfo from host (nv50) (88.25 KB, text/plain)
2019-06-14 14:43 UTC, Andrew Randrianasulu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Randrianasulu 2019-06-14 14:39:00 UTC
Created attachment 144542 [details]
glxinfo from guest

Hi!

I was testing virgl on nv50 and llvmpipe. It was working last year, showing OpenGL 3.3 in Linux guest. Now it only displays OpenGL 2.1 [but still works]

 LIBGL_ALWAYS_SOFTWARE=1 qemu-system-x86_64  -enable-kvm -m 1G -display sdl,gl=on -soundhw es1370 -cdrom /mnt/sdb1/slax-14_06_2019-private0.iso -vga virtio -usbdevice mouse -smp 3 -cpu max
qemu-system-x86_64: -usbdevice mouse: '-usbdevice' is deprecated, please use '-device usb-...' instead
gl_version 33 - core profile enabled
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_ALPHA8)
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_ALPHA16)
GLSL feature level 330
                               
In guest:
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Red Hat (0x1af4)
    Device: virgl (0x1010)
    Version: 19.2.0
    Accelerated: yes
    Video memory: 0MB
    Unified memory: no
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
                       
OpenGL version string: 2.1 Mesa 19.2.0-devel (git-83829abe03)
Comment 1 Andrew Randrianasulu 2019-06-14 14:43:14 UTC
Created attachment 144543 [details]
glxinfo from host (llvmpipe)
Comment 2 Andrew Randrianasulu 2019-06-14 14:43:41 UTC
Created attachment 144544 [details]
glxinfo from host (nv50)
Comment 3 Ilia Mirkin 2019-06-14 14:45:25 UTC
FWIW GL_ALPHA8/16 are not valid in a core profile.
Comment 4 Ilia Mirkin 2019-06-14 16:25:00 UTC
Looks like ARB_framebuffer_sRGB is not provided for some reason by virgl.

There was recently reworked in virgl to try to be more precise, esp in ES, and I suspect something here ended up as a casualty...

   extensions->EXT_framebuffer_sRGB =
         screen->get_param(screen, PIPE_CAP_DEST_SURFACE_SRGB_CONTROL) &&
         extensions->EXT_sRGB;

Where EXT_sRGB is controlled by:
      { { o(EXT_sRGB) },
        { PIPE_FORMAT_A8B8G8R8_SRGB,
          PIPE_FORMAT_B8G8R8A8_SRGB,
          PIPE_FORMAT_R8G8B8A8_SRGB },
         GL_TRUE }, /* at least one format must be supported */

And the cap is controlled by:
   case PIPE_CAP_DEST_SURFACE_SRGB_CONTROL:
      return vscreen->caps.caps.v2.capability_bits & VIRGL_CAP_SRGB_WRITE_CONTROL;

Probably one or both of those is false for some silly reason. Could even be due to an older version of the virgl "server" component which doesn't include that capability bit.
Comment 5 Andrew Randrianasulu 2019-06-15 07:08:17 UTC
(In reply to Ilia Mirkin from comment #4)
> Looks like ARB_framebuffer_sRGB is not provided for some reason by virgl.


Oddly enough, when I rebuild my live-dvd with new (5.1.6 , 64-bit) kernel - it started  to show 3.3/3.1 :} So, only old (4.12.0 in my case) kernel(s) were affected.
Comment 6 Gert Wollny 2019-06-16 09:17:10 UTC
With Kernel 4.16.0 support for the v2 caps data was introduces, and caps.caps.v2.capability_bits is part of these v2 caps. So if the guest kernel is older than this cap will not be reported.

We'll see whether it makes sense to work around this or simply document the minimal requirements better.
Comment 7 Gert Wollny 2019-06-17 07:01:11 UTC
This should fix it: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1108
Comment 8 Juan A. Suarez 2019-06-25 11:15:26 UTC
The MR was merged, and the fix included in Mesa 19.1.1.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.