Samples missing ?

[nyue]

I have been able to build ospray_studio

In the menu, there was option to load some sample scenes but nothing happens.

Do I need to install other packages or set some CMake settings in order for the samples scenes to show up ?

Cheers

[BruceCherniak]

Hello. No, you don't need additional packages for the simple demo scenes. file -> Demo scene -> tutorial_scene generates two simple planes. Does that show up?

What OS, etc. are you using? Do the OSPRay examples ospExamples show up? (I see in another ticket that you've built ospray from source as well)

[nyue]

OS : Ubuntu 18.04 Intel, GCC 7.5.0

ospExamples are fine, only opsStudio showing blank screen when loading demos or geometry files e.g. OBJ

[BruceCherniak]

Apologies for delay, was on vacation. Hmm, this is very unusual. And the console isn't showing any obvious error messages when launching Studio? Can you load one of the simple demo scenes (such as sphere) and then type "p" that should print the entire scene graph to the console. paste that here and I'll take a look.

[nyue]

Output from "p"

OSPRay Studio
OpenImageDenoise is available
GUI mode
main_frame : frame
  windowSize : vec2i [(1024,768)]
  framebuffer : framebuffer
    floatFormat : bool [0]
    size : vec2i [(1024,768)]
    colorFormat : string [sRGB]
    exposure : float [1]
    contrast : float [1.1759]
    shoulder : float [0.9746]
    midIn : float [0.18]
    midOut : float [0.18]
    hdrMax : float [6.3704]
    acesColor : bool [1]
    sRGB : bool [1]
  scale : float [1]
  scaleNav : float [0.5]
  camera : camera_perspective
    position : vec3f [(1,1,4.4641)]
    direction : vec3f [(0,0,-1)]
    up : vec3f [(0,1,0)]
    nearClip : float [0]
    imageStart : vec2f [(0,0)]
    imageEnd : vec2f [(1,1)]
    lookAt : vec3f [(1,1,1)]
    motion blur : float [0]
    shutter : range1f [[0,0]]
    fovy : float [60]
    aspect : float [1.33333]
    apertureRadius : float [0]
    focusDistance : float [3.4641]
    adjustAperture : bool [0]
    architectural : bool [0]
    stereoMode : int [0]
    interpupillaryDistance : float [0.0635]
  renderer : renderer_pathtracer
    type : string [pathtracer]
    pixelSamples : int [1]
    maxPathLength : int [20]
    minContribution : float [0.001]
    varianceThreshold : float [0]
    backgroundColor : rgba [(0.1,0.1,0.1,1)]
    pixelFilter : int [2]
    lightSamples : int [-1]
    roulettePathLength : int [5]
    maxContribution : float [1e+06]
    geometryLights : bool [1]
    backgroundRefraction : bool [0]
  world : world
    dynamicScene : bool [0]
    compactMode : bool [0]
    robustMode : bool [0]
    materialref : reference_to_material
    sphere_generator : generator_sphere
      parameters : Node
        center : vec3f [(1,1,1)]
        radius : float [1]
        color : rgba [(1,1,1,1)]
      xfm : transform
        translation : vec3f [(0,0,0)]
        rotation : quaternionf [{ r = 1, i = 0, j = 0, k = 0 }]
        scale : vec3f [(1,1,1)]
        dynamicScene : bool [0]
        compactMode : bool [0]
        robustMode : bool [0]
        geometry : geometry_spheres
          isClipping : bool [0]
          visible : bool [1]
          invertNormals : bool [0]
          radius : float [1]
          sphere.position : Data
          color : rgba [(1,1,1,1)]
  navMode : bool [0]
  baseMaterialRegistry : materialRegistry
    rType : string [pathtracer]
    sgDefault : obj
      handles : Node
        pathtracer : Node
      kd : rgb [(0.8,0.8,0.8)]
      ks : rgb [(0,0,0)]
      ns : float [10]
      d : float [1]
      tf : rgb [(0,0,0)]
  lights : lights
    default-ambient : ambient
      visible : bool [0]
      color : rgb [(1,1,1)]
      intensity : float [1]
      intensityQuantity : uchar [1]
      type : string [ambient]

[BruceCherniak]

Very odd indeed. The sphere is there in the scene and the camera is set correctly. I'm wondering if it might be your desktop visual format (for some odd reason). Can you try view -> framebuffer -> float format (checkbox) which will change the framebuffer from an 8-bit to float format and change the texture format we use to copy into the OpenGL window.

[nyue]

No difference

I am also including my graphics driver information just in case it might be useful

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 710/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.144
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:

[BruceCherniak]

Does batch mode generate an image? Please try ospStudio batch <file.obj> This should run and generate an image file (png format by default) of the framebuffer. This will help narrow whether anything is even rendering through Studio to OSPRay.

[nyue]

Batch mode works

$ ospStudio batch monkey.obj 

OSPRay Studio
OpenImageDenoise is available
Batch mode
...importing files!
Importing: monkey.obj
... found 32 triangles and 468 quads.
...finished import!
No cameras imported or invalid camera index specified
Warning: saving a 32-bit float buffer as PNG; color space will be limited.
Saved to ospBatch.00000.png
...finished!

[BruceCherniak]

Thanks for your patience. This is a weird one.

So, we know that the scene is loading, ospray is rendering the scene, and then studio is grabbing that buffer correctly. We also know that imGui is working from the screen grabs above - and ImGui requires an OpenGL backend.

That really only leaves GLFW and the interaction with the system OpenGL. Which GLFW do you have installed? Did you build it from source? Or did the ospray_studio FetchContent build it during the Studio build?

Since the OSPRay examples ospExamples are running, we can definitely say that there is a combination that works.... somewhere.

[nyue]

I am using the system's GLFW. My system is an Ubuntu 18.04 box

My cmake configuration looks like this

#!/bin/sh
rm -f CMakeCache.txt
export ospray_DIR=$HOME/systems/ospray/head/lib/cmake/ospray-2.7.0
export openvkl_DIR=$HOME/systems/openvkl/1.0.0/lib/cmake/openvkl-1.0.0
export embree_DIR=$HOME/systems/embree/3.13.1/lib/cmake/embree-3.13.1
export rkcommon_DIR=$HOME/systems/rkcommon/1.7.0/lib/cmake/rkcommon-1.7.0
export TBB_ROOT=$HOME/systems/TBB/2021.3.0
export pybind11_DIR=$HOME/systems/pybind11/2.6.2/share/cmake/pybind11
export IlmBase_ROOT=$HOME/systems/OpenEXR/2.4.0
export OpenEXR_ROOT=$HOME/systems/OpenEXR/2.4.0
export OPENIMAGEIO_ROOT=$HOME/systems/oiio/head-py2
cmake \
	-D ENABLE_OPENIMAGEIO=OFF \
	-D ENABLE_EXR=OFF \
	-D ENABLE_OPENVDB=OFF \
	-D CMAKE_BUILD_TYPE=Release \
	-D CMAKE_INSTALL_PREFIX=$HOME/systems/ospray_studio/head \
	-G "Ninja" \
	../ospray_studio_git

nyue@head0:/data2/nyue/projects/OSPray/studio/build$ ldd ospStudio

	linux-vdso.so.1 (0x00007fff03eb2000)
	libospray_sg.so => /data2/nyue/projects/OSPray/studio/build/libospray_sg.so (0x00007f9a02233000)
	libospray.so.2 => /home/nyue/systems/ospray/head/lib/libospray.so.2 (0x00007f9a01ff5000)
	librkcommon.so.1 => /home/nyue/systems/rkcommon/1.7.0/lib/librkcommon.so.1 (0x00007f9a01dd6000)
	libtbb.so.12 => /home/nyue/systems/TBB/2021.3.0/lib/libtbb.so.12 (0x00007f9a01b75000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f9a018e9000)
	libglfw.so.3 => /usr/lib/x86_64-linux-gnu/libglfw.so.3 (0x00007f9a016cc000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9a01343000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9a00fa5000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9a00d8d000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9a00b6e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a0077d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9a02a18000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9a00579000)
	libtbbmalloc.so.2 => /home/nyue/systems/TBB/2021.3.0/lib/libtbbmalloc.so.2 (0x00007f9a00336000)
	libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f9a00105000)
	libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f99ffe4f000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f99ffc47000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f99ff90f000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f99ff704000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f99ff501000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f99ff2fb000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f99ff0f1000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f99feec9000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f99fecb7000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f99feaad000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f99fe8a7000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f99fe6a3000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f99fe49d000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f99fe288000)

[BruceCherniak]

I will look around to find an Ubuntu 18.04 system -- all of ours have been upgraded to at least 19.x. I assume that you have tried the binaries released on github and they produce the same result? Just trying to determine if we're chasing a build issue or a library issue. (https://github.com/ospray/ospray_studio/releases/download/v0.8.0/ospray_studio-0.8.0-linux.tar.gz)

[nyue]

I have tried out the pre-built binary. The screen still shows nothing with the various demo scenes.

[BruceCherniak]

I just installed a completely fresh Ubuntu 18.04 image, with very latest packages updates. I additionally installed mesa-utils, as there is no gpu in this machine, so OpenGL is coming through llvmpipe. The github pre-built binary packages run fine. This is extremely puzzling.

That the background color you are seeing matches the gray we set by default suggests that something has rendered - that color comes back from OSPRay and not directly set in the window. If you select view -> renderer -> backgroundColor (click in the box and it will bring up a color picker). Drag that color around. Does the window change at all?

[nyue]

No. Dragging the color around does result in any update to the window.

I guess this indicates that the problem is likely on my OS/Systems/Drivers setup rather than ospStudio itself.

[BruceCherniak]

on a wild guess.... did the v0.7.0 release binaries work on your system? (https://github.com/ospray/ospray_studio/releases/download/v0.7.0/ospray_studio-0.7.0-linux.tar.gz)

[nyue]

No it does not work.

I tried changing the background color too, it did not respond to the color change event.

[BruceCherniak]

Ok, thanks for trying that. My thought there was that we updated some of the 3rd party libraries (ImGui included) for the v0.8.0 release and there might be an interaction.

This sure seems like a swap buffers problem. Since you've compiled Studio from source, a very simple check for this would be to comment out the glfwSwapBuffers(glfwWindow); call, and add glDrawBuffer(GL_FRONT); right below the // set initial OpenGL state. Expect flickering and other artifacts, but this will help us confirm that's what's going on.

[nyue]

Doing the change from glfwSwapBuffers(glfwWindow); to glDrawBuffer(GL_FRONT); resulted in my Ubuntu 18.04 workstation freezing, I can't even ssh into the box so I can't help on that front as it meant I had to do a hard reset of the entire machine.

[nyue]

I took a different hardware to try and isolate the problem

I have now build OSPray Studio on the Jetson Nano (Picocluster 5H). This is an ARM64 CPU (it does have nvidia drivers). It is running Ubuntu 18.04

I am building from the 0.8.0 source tar ball with the following libraries (build from source for my Jetson Nano)

#!/bin/sh                                                                                                                         
rm -f CMakeCache.txt
export ospray_DIR=/piconfs/systems/OSPray/head/lib/cmake/ospray-2.7.0
export openvkl_DIR=/piconfs/systems/openvkl/1.0.0/lib/cmake/openvkl-1.0.0
export embree_DIR=/piconfs/systems/embree/3.13.1/lib/cmake/embree-3.13.1
export rkcommon_DIR=/piconfs/systems/rkcommon/1.7.0/lib/cmake/rkcommon-1.7.0
export TBB_ROOT=/piconfs/systems/tbb/2021.2.0
export pybind11_DIR=/piconfs/systems/pybind11/2.7.1/share/cmake/pybind11
cmake \
        -D ENABLE_OPENIMAGEIO=OFF \
        -D ENABLE_EXR=OFF \
        -D ENABLE_OPENVDB=OFF \
        -D CMAKE_BUILD_TYPE=Release \
        -D CMAKE_INSTALL_PREFIX=/piconfs/systems/ospray_studio/head \
        -G "Ninja" \
        ../ospray_studio-0.8.0

I am still getting nothing draw (except for the grey background)

Changing color of the background has no effect.

Hope this additional information is of some use.

[BruceCherniak]

Thanks for trying some different hardware. Very helpful info.

I assume that all packages are apt upgrade to the most recent? 18.04 has been around for quite a while.

We have tested this with various Intel, AMD, and nvidia display out, so the nvidia drivers shouldn't be a problem. Any chance you can switch to mesa drivers, just as a test?

Your GeForce GT 710 is the half-height/passively-cooled card? I may have one of those around. Need to check.

That change that hung your machine really really shouldn't have - all of our libraries are ring-3 user-mode code with no kernel components. I suspect that the unrestrained framerate of frontbuffer rendering caused problems with your gpu drivers. A small sleep in place of the glfwSwapBuffers is not ideal, but should help test that frontbuffer theory.

I'm also devising some other experiments to try. But, we literally do very little to get the OSPRay framebuffer into the window - a single simple OpenGL textured quad.

[BruceCherniak]

Another thought, since removing the glfwSwapBuffers appears to be a problem, just set glDrawBuffer(GL_FRONT_AND_BACK) and leave the glfwSwapBuffers in place. Should be the same effect.

[nyue]

I tried both variation, nothing shows, just the grey background

  // swap buffers                                                               
  glfwSwapBuffers(glfwWindow);
  glDrawBuffer(GL_FRONT_AND_BACK);

  glDrawBuffer(GL_FRONT_AND_BACK);
  // swap buffers                                                               
  glfwSwapBuffers(glfwWindow);

[BruceCherniak]

the glDrawBuffer(GL_FRONT_AND_BACK); goes up with the other // set initial OpenGL state (around line 385) - down near the glfwSwapBuffers is after the drawing code and too late. If this is where you placed in and still nothing rendered then that suggests that even drawing a basic textured quad isn't working with the ImGui OpenGL2 backend - yet oddly, ImGui itself is rendering just fine. We've chosen the ImGui OpenGL2 backend because it represents the very lowest common denominator for many different older systems.

[BruceCherniak]

Another quick something to try. The OSPRay Examples ospExamples work. OSPRay Studio does not. Do the OpenVKL examples work from these release binaries? https://github.com/openvkl/openvkl/releases/tag/v1.0.1

[nyue]

I will build openvkl 1.0.1 later but with openvkl 1.0.0, running the example, I see this

[BruceCherniak]

Thanks! That's useful! OpenVKL uses the same OpenGL2 backend that Studio uses. I'll look for nuanced differences between the two.

[BruceCherniak]

Something else to prove that the texture is being updated correctly and simply not show is to add the line ImGui::Image(...) as below. Add it between the glEnd() and the glDisable(GL_FRAMEBUFFER_SRGB).

  glEnd();
  ImGui::Image((void*)(intptr_t)framebufferTexture, ImVec2(fbSize.x, fbSize.y), ImVec2(0,1), ImVec2(1,0));
  glDisable(GL_FRAMEBUFFER_SRGB);

When it runs, you might have to adjust the window size that pops up (labeled debug), but the image should be there.

[nyue]

Here is what I see, I did some window resizing in the hope that something get refreshed ... no luck

[BruceCherniak]

even changing background color still shows the same old gray™? If so, I've been looking in the wrong place and it implies that the OpenGL texture isn't even being updated and that:

      glBindTexture(GL_TEXTURE_2D, framebufferTexture);
      glTexImage2D(GL_TEXTURE_2D,
          0,
          showAlbedo ? gl_rgb_format : gl_rgba_format,
          fbSize.x,
          fbSize.y,
          0,
          showDepth ? GL_LUMINANCE : (showAlbedo ? GL_RGB : GL_RGBA),
          glType,
          showDepth ? pDepthCopy : mappedFB);

is failing.

[nyue]

Yes, changing the background color has no effect

[BruceCherniak]

Please put a glGetError(); call just after the glTexImage2D(...) (line 859-ish).

      GLenum error = glGetError();
      if (error != GL_NO_ERROR)
        std::cout << "glError : " << error;

If there is a GL error here, this will spew the error to console.

[nyue]

Nothing was printed out on the console

      glBindTexture(GL_TEXTURE_2D, framebufferTexture);
      glTexImage2D(GL_TEXTURE_2D,
          0,
          showAlbedo ? gl_rgb_format : gl_rgba_format,
          fbSize.x,
          fbSize.y,
          0,
          showDepth ? GL_LUMINANCE : (showAlbedo ? GL_RGB : GL_RGBA),
          glType,
          showDepth ? pDepthCopy : mappedFB);
      GLenum error = glGetError();
      if (error != GL_NO_ERROR)
        std::cout << "glError : " << error;

      frame->unmapFrame(mappedFB);

[BruceCherniak]

Wow 😳, that is a really finicky setup.

How about line 852:

          showAlbedo ? gl_rgb_format : gl_rgba_format,

to

          showAlbedo ? GL_RGB32F : GL_RGBA32F,

[BruceCherniak]

please post the results of: nvidia-smi
This will give some more info about your gpu and driver versions.

[nyue]

nyue@head0:~/projects/VTK/VTKTools/houdini_build$ nvidia-smi

Mon Sep 27 12:48:35 2021       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.144                Driver Version: 390.144                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GT 710      Off  | 00000000:01:00.0 N/A |                  N/A |
| N/A   52C    P0    N/A /  N/A |    478MiB /   980MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0                    Not Supported                                       |
+-----------------------------------------------------------------------------+

[nyue]

Tried the showAlbedo change, it makes no difference

      glBindTexture(GL_TEXTURE_2D, framebufferTexture);
      glTexImage2D(GL_TEXTURE_2D,
          0,
                   //showAlbedo ? gl_rgb_format : gl_rgba_format,                                                                                                       
                   showAlbedo ? GL_RGB32F : GL_RGBA32F,
          fbSize.x,
          fbSize.y,
          0,
          showDepth ? GL_LUMINANCE : (showAlbedo ? GL_RGB : GL_RGBA),
          glType,
          showDepth ? pDepthCopy : mappedFB);
      GLenum error = glGetError();
      if (error != GL_NO_ERROR)
        std::cout << "glError : " << error;

      frame->unmapFrame(mappedFB);

[BruceCherniak]

Does glPixelStorei(GL_UNPACK_ROW_LENGTH, 0); immediately before the glTexImage2D(...) call make any difference?

[nyue]

Unfortunately, it does not make a difference.

      glBindTexture(GL_TEXTURE_2D, framebufferTexture);

      glPixelStorei(GL_UNPACK_ROW_LENGTH, 0);
      glTexImage2D(GL_TEXTURE_2D,
          0,
                   //showAlbedo ? gl_rgb_format : gl_rgba_format,                                                                                                       
                   showAlbedo ? GL_RGB32F : GL_RGBA32F,
          fbSize.x,
          fbSize.y,
          0,
          showDepth ? GL_LUMINANCE : (showAlbedo ? GL_RGB : GL_RGBA),
          glType,
          showDepth ? pDepthCopy : mappedFB);
      GLenum error = glGetError();
      if (error != GL_NO_ERROR)
        std::cout << "glError : " << error;

[BruceCherniak]

Given that you've got a GT 710 and we're using a GL2 context, could this be sRGB related?
Can you comment out the following?

glfwWindowHint(GLFW_SRGB_CAPABLE, GLFW_TRUE);
...
  if (uiDisplays_sRGB && !frameBuffer.isSRGB())
    glEnable(GL_FRAMEBUFFER_SRGB);
...
  glDisable(GL_FRAMEBUFFER_SRGB);

so that we're not asking for an sRGB FrameBuffer under any circumstances?

Sure wish I could reproduce this locally.

[nyue]

No difference

    // Start new frame and reset frame timing interval start                                                                                                            
    displayStart = std::chrono::high_resolution_clock::now();
    startNewOSPRayFrame();
  }

  // Allow OpenGL to show linear buffers as sRGB.                                                                                                                       
  //if (uiDisplays_sRGB && !frameBuffer.isSRGB())                                                                                                                       
  //  glEnable(GL_FRAMEBUFFER_SRGB);                                                                                                                                    

  // clear current OpenGL color buffer                                                                                                                                  
  glClear(GL_COLOR_BUFFER_BIT);

  // render textured quad with OSPRay frame buffer contents                                                                                                             
  vec2f border(0.f);

[BruceCherniak]

I just installed the oldest nvidia card I have GT218 ION with the nvidia 340 drivers on Ubuntu 20.04 (the only install I can change hardware on) and things still work.

My Ubuntu 18.04 install is a VM in our office and has no gpu, running the mesa llvmpipe OpenGL drivers. This too works.

We've stripped back the major differences between Studio's use of the ImGUI OpenGL2 backend and OpenVKL examples, with no luck there.

At this point, I'm baffled on your setup.

I'm going to have to spend some time with the code to come up with some other ideas for the code.

I would be interested to know if either switching to the mesa drivers or a more up-to-date Ubuntu 20.04 work for you, but I would understand your reluctance to try those changes.

[nyue]

I'll look into resurrecting an old Toshiba laptop and try the Ubuntu 20.04 route and report back. ETA 4-5 days.

[BruceCherniak]

Unfortunately, I expect that hardware will be different enough to not provide insight into this particular problem. And, it'll probably work without an issue. I suspect the GT 710 and driver combo is the root cause here - maybe not a driver bug, per se, but something odd.

I'll continue down the path of minor changes to our code. I could create a special branch that uses the ImGui GLFW+OpenGL3 backend (like OSPRay examples), but since the OpenGL2 has been working for the vast majority of systems (and still does for VKL examples) I can't say when that would make it into a stable release.

[nyue]

But I did build with a completely different hardware, ARM64, different GPU, Tegra and different driver version and still have gray background is baffling me too.

[nyue]

Testing with toshiba laptop - Ubuntu 20.04 (with latest updates)

Linux toshiba 5.11.0-37-generic #41~20.04.2-Ubuntu SMP Fri Sep 24 09:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Still getting no display of sample demo scene e.g. sphere
Changing background colour has no effect

Running pre-built binary - ospray_studio-0.8.0-linux.tar.gz

glxinfo (relevant bits)

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: nouveau (0x10de)
    Device: NVC1 (0xdec)
    Version: 21.0.3
    Accelerated: yes
    Video memory: 1015MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.3
    Max compat profile version: 4.3
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: nouveau
OpenGL renderer string: NVC1
OpenGL core profile version string: 4.3 (Core Profile) Mesa 21.0.3
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:

[BruceCherniak]

Mind blown. I'll keep digging.

[nyue]

Testing to Dell Latitude E6410 - CentOS 7.7.1908

Mesa driver

ospray_studio-0.8.1-linux.tar.gz

Still having the gray screen, nothing showing up with the built in demo scenes.

[BruceCherniak]

On the two systems where you're using the mesa driver (nouveau in both cases?) can you please try to use the llvmpipe OpenGL driver?

As per https://docs.mesa3d.org/envvars.html, export GALLIUM_DRIVER=llvmpipe ought to do it.

[BruceCherniak]

Sorry to report I still cannot create a failing install. I have tried several older systems and various older NV card using both NV and mesa drivers.

My install steps:

1. install Ubuntu 18.04.6 using image found on https://releases.ubuntu.com/18.04/
   (specifically https://releases.ubuntu.com/18.04/ubuntu-18.04.6-desktop-amd64.iso)
2. fresh default install completely erasing any existing partitions, taking all other defaults during install.
3. sudo apt install mesa-utils for glxinfo, to verify gfx driver and OpenGL version
4. Download OSPRay Studio v0.8.1 pre-built linux package from https://github.com/ospray/ospray_studio/releases/tag/v0.8.1
   (specifically https://github.com/ospray/ospray_studio/releases/download/v0.8.1/ospray_studio-0.8.1-linux.tar.gz)
5. cd ~/Downloads and tar xf ospray_studio-0.8.1-linux.tar.gz
6. cd ospray_studio-0.8.1-Linux/bin/
7. ./ospStudio then select menu File -> Demo scene -> wavelet
   This will verify the default mesa drivers.

Then, to install nvidia drivers:

8. sudo ubuntu-drivers install
9. reboot and repeat (7)

After that, I'll verify again after making sure all packages are up to date.

10. sudo apt update && sudo apt upgrade

But, I haven't installed any other software than this.

[BruceCherniak]

As I mentioned the other day, we have found a way to reproduce this problem and it only seems to occur on certain architectures. Most reliable failure seems to be a SandyBridge QEMU ubuntu install, and it looks like the frame completion flag isn't being triggered, which is causing the code to skip where we would start a new frame.

A simple workaround that has resolved this deadlock for me is in MainWindow.cpp MainWindow::display(), changing:

   if (frame->frameIsReady()) {

to

  if (frame->frameIsReady() || frame->frameProgress() == 1.f) {

I wonder if you might be able to try this at some point?

[nyue]

@BruceCherniak

Works like a charm. Thank you.

I have rebuild with the latest OSPRay studio with OSPRay 2.8.0 and all the dependencies.

Confirming that the call to frame->frameProgress() and the comparison is essential in getting it to work.

Cheers

[BruceCherniak]

Thank you for verifying. I don't know what the ultimate fix will look like, but this tells us a whole lot and allows you to try some things out. Cool. That one was really keeping up and night. :-)

Cheers.

[BruceCherniak]

Hi Nicholas, I have merged a fix for this issue into the gitlab devel branch (6bd05fb). When you get chance, would you mind trying the latest devel branch on a couple of the system that failed for you previously? The nano cluster would be especially interesting to test on.

I have verified it across several VM installs that exhibited the problem, as well as making sure it doesn't introduce artifacts in other situations.

[nyue]

I have now built the branch the old Intel chip I have, it is working just fine. Thank you.

The Jetson Nano cluster is misbehaving so it might take a couple more days for me to get you an answer. I am also interested to see how the fixes works out on ARM CPU

[BruceCherniak]

Hmmm. Bummer. Recall that the fix is only on the devel branch at this point. You did remember to git checkout devel? The git clone will default to the master branch.

[nyue]

Ha! In my haste I did not checkout devel branch.

Rebuilt everything on the devel branch. All is well.

So on my Jetson Nano ARM64 running Ubuntu 18.04

I have loaded all the demo scenes with no problem, with the known caveat of there being no denoiser (will follow up in a different conversation) as this tests is not on an Intel CPU.

Cheers