Breaking in linux with intel GPU via mesa

[Joilnen]

System Information

• Ogre Version: :grey_question: 9ee143ab0f1cf34788e1bfac29f55df560070b7e
• Operating System / Platform: :grey_question: linux
• RenderSystem: :grey_question: RenderSystem_GL3Plus
• GPU: :grey_question: intel via mesa

Detailled description

Crash when I try to run samples

---

*** Starting GLX Subsystem ***

---

GL3PlusRenderSystem::_createRenderWindow "High Dynamic Range (HDR) Sample", 1366x0 windowed miscParams: FSAA=0 SDL2x11=140728674451464 gamma=Yes parentWindowHandle=14680078 reverse_depth=Yes title=High Dynamic Range (HDR) Sample vsync=No X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 19 Current serial number in output stream: 21

[darksylinc]

Hi!

That's a weird bug because we tried to create a 1366x0 window, which is an invalid resolution. Indicating a problem with SDL, X or monitor setup.

Also I'm going to need more info:

• A screenshot of the Ogre config dialog
• ogre.cfg
• Linux Distro
• Desktop Environment (GNOME? xfce? KDE?)
• Wayland or X11?
• Output of the following: LANG=C glxinfo -B | grep -i '\(direct rendering\|opengl\|profile\)'
• Output of the following: ps aux | grep Xorg
• Output of the following: sudo env LANG=C X -version # if you don't have root access, try to tell the version of Xorg e.g. via package manager
• Output of the following: uname --all

[Joilnen]

A screenshot of the Ogre config dialog
ogre.cfg
Linux Distro: Arch
Desktop Environment (GNOME? xfce? KDE?): dwm
Wayland or X11? X11
Output of the following:
LANG=C glxinfo -B | grep -i '\(direct rendering\|opengl\|profile\)'
LANG=C glxinfo -B | grep -i '\(direct rendering\|opengl\|profile\)'
direct rendering: Yes
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 400 (BSW)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.1.4
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.0 Mesa 21.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Output of the following:

    ps aux | grep Xorg
joilnen      477  6.2  1.2 716308 24256 tty2     Sl+  13:25  34:22 /usr/lib/Xorg :0 vt2
joilnen    44670  0.0  0.1   8952  2176 pts/2    S+   22:39   0:00 grep Xorg

Output of the following:

    sudo env LANG=C X -version # if you don't have root access, try to tell the version of Xorg e.g. via package manager
    X.Org X Server 1.20.12
X Protocol Version 11, Revision 0
Build Operating System: Linux Archlinux
Current Operating System: Linux dijkstra 5.12.15-arch1-1 #1 SMP PREEMPT Wed, 07 Jul 2021 23:35:29 +0000 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=ab9b3a43-ae95-4b38-94c9-ec6e19edc281 rw loglevel=3 quiet
Build Date: 08 July 2021  08:00:40PM

Output of the following:

    uname --all
Linux dijkstra 5.12.15-arch1-1 #1 SMP PREEMPT Wed, 07 Jul 2021 23:35:29 +0000 x86_64 GNU/Linux

[darksylinc]

OK so your system HW should be supported and drivers are up to date. In theory your HW should support Vulkan too.

What I noticed that is unknown to me is dwm. I only know it by name but never used it. I suspect some incompatibility with dwm is causing the problem.

I wonder at this part of Samples/2.0/Common/src/GraphicsSystem.cpp:

mSdlWindow = SDL_CreateWindow(
            windowTitle.c_str(),    // window title
            posX,               // initial x position
            posY,               // initial y position
            width,              // width, in pixels
            height,             // height, in pixels
            SDL_WINDOW_SHOWN
              | (fullscreen ? SDL_WINDOW_FULLSCREEN : 0) | SDL_WINDOW_RESIZABLE );

Whether height is 0 or 768.

Perhaps if your monitor's resolution is actually 1366x768 dwm doesn't like the window covering the whole screen and wants us to use a smaller resolution

The other thing I can think of is that XGetWindowAttributes( xDisplay, mWindow, &windowAttrib ); in GLXWindow::windowMovedOrResized (or any other use of XGetWindowAttributes) from RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp is outputting 0.

Perhaps we should use height = std::max( 1u, height );

[Joilnen]

I recompiled with this change, but still getting 0 height, all times that I set sizes less than 1024 I get 0 width too and crashs, it try to create the thin window and crashs

132 void GLXWindow::create( PixelFormatGpu depthStencilFormat, const NameValu ↳ ePairList *miscParams ) 133 {
134 Display *xDisplay = mGLSupport->getXDisplay(); 135 uint8 samples = 0;
136 bool hidden = false; . . . 501 502 XGetWindowAttributes(xDisplay, mWindow, &windowAttrib);
503 504 left = windowAttrib.x; 505 top = windowAttrib.y; 506 std::max(1, windowAttrib.height); 507 setFinalResolution( windowAttrib.width, windowAttrib.height ) ; 508 } 509 510 glxDrawable = mWindow;

[luciddream-tsin]

Hi @darksylinc, this is a bug because of there have two space after 'x' in "1366 x 768"; The following code work correctly.

        Ogre::ConfigOptionMap::iterator opt = cfgOpts.find( "Video Mode" );
        if( opt != cfgOpts.end() && !opt->second.currentValue.empty() )
        {
            // Ignore leading space
            const Ogre::String::size_type start = opt->second.currentValue.find_first_of( "012356789" );
            // Get the width and height
            Ogre::String::size_type widthEnd = opt->second.currentValue.find( ' ', start );
            // we know that the height starts 3 characters after the width and goes until the next space

            // --------------------------------alter---beg-----------------------------------------------
            // Ogre::String::size_type heightEnd = opt->second.currentValue.find( ' ', widthEnd + 3 );
            Ogre::String::size_type heightEnd = opt->second.currentValue.find( ' ', widthEnd + 4 );
            // --------------------------------alter---end-----------------------------------------------

            // Now we can parse out the values
            width = Ogre::StringConverter::parseInt( opt->second.currentValue.substr( 0, widthEnd ) );

            
            // --------------------------------alter---beg-----------------------------------------------
            // height = Ogre::StringConverter::parseInt(opt->second.currentValue.substr( widthEnd + 3, heightEnd ) );
            height = Ogre::StringConverter::parseInt(opt->second.currentValue.substr( widthEnd + 4, heightEnd ) );
            // --------------------------------alter---end-----------------------------------------------

        }

[luciddream-tsin]

and "1280 x 1024" was ok, because of the 1024 has 4 character.

[luciddream-tsin]

The source at RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXGLSupport.cpp, also need to fix: line 380-390,

            if((opt = mOptions.find("Video Mode")) != end)
            {
                String val = opt->second.currentValue;
                String::size_type pos = val.find('x');

                if (pos != String::npos)
                {
                    w = StringConverter::parseUnsignedInt(val.substr(0, pos));
                    h = StringConverter::parseUnsignedInt(val.substr(pos + 1));
                }
            }

[luciddream-tsin]

The essential of this problem is, all of the paramters have the same length, so the num of space is variant in different case:

[Joilnen]

Could you to create a patch to fix it ?

[luciddream-tsin]

okay, I fixed it, now it worked will.

[darksylinc]

Out of curiosity do you know what locales were in use?

I suspect this bug may be locale related, or something special happening in parseUnsignedLong (you can dump locales via the env command in Linux.

Because parseUnsignedLong should ignore leading space

[luciddream-tsin]

some LC related information， LANGUAGE=zh_CN:zh:en_US:en LC_ADDRESS=zh_CN.UTF-8 LC_NAME=zh_CN.UTF-8 LC_MONETARY=zh_CN.UTF-8 LC_PAPER=zh_CN.UTF-8 LANG=zh_CN.UTF-8 LC_NUMERIC=zh_CN.UTF-8 and i am learning to read the code:

    template <char SEP = ' ', typename... Args>
    from_chars_result from_chars_all( const char *first, const char *last, Args &...args )
    {
        from_chars_result res = { first, errc() };
        return ( ... && ( ( res.ptr == first || skip_sep( res.ptr, last, SEP ) ) &&
                          ( skip_space( res.ptr, last, SEP ), res = from_chars( res.ptr, last, args ),
                            res.ec == errc() ) ) )
               ? skip_space( res.ptr, last, SEP ),
               res : from_chars_result{ first, errc::invalid_argument };
    }

Is it just remove space?

[darksylinc]

Aha! Thank you!

Yeah it's using an alternate path that I don't usually use (either that, or it's a problem caused by the chinese locale that OgreNext should account for).

I'm on vacation now, but once I get back I can take a look at this.

Thank you.

[darksylinc]

I've reopened the ticket to track the underlying problem

[darksylinc]

I've reverted your PR and Eugene added a proper fix.

The underlying problem was fixed in https://github.com/OGRECave/ogre-next/commit/99d8e478db84d855cdcf575a5fe53afdc1c80212

When OgreNext was compiled with C++17 support; from_chars_all would be used (which is faster) but it was buggy.

from_chars_all( " 900" ) was supposed to return 900, but returned 0 instead.

That's why "it works on my machine" but it was broken on yours. The difference was the default C++ version in your/my compiler.

I could repro the bug on my machine when setting CMAKE_CXX_STANDARD to 17.

It should work now.

[luciddream-tsin]

thanks!