Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sweethome3d: 6.3 -> 6.4.2 #97129

Merged
merged 1 commit into from Nov 17, 2020
Merged

Conversation

raboof
Copy link
Member

@raboof raboof commented Sep 4, 2020

Tested with: nix-shell -p sweethome3d.application and then
MESA_GL_VERSION_OVERRIDE=2.1 sweethome3d (just like I need to do for 6.3)

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@jonringer
Copy link
Contributor

This crashes for me without MESA_GL_VERSION_OVERRIDE=2.1 should we just add a wrapper for this to be always true?

@raboof
Copy link
Member Author

raboof commented Sep 4, 2020

This crashes for me without MESA_GL_VERSION_OVERRIDE=2.1 should we just add a wrapper for this to be always true?

I would be in favour, but I didn't feel qualified to make the call :).

I'll add it since I now heard from several people that it didn't work without it and did work with it, and I never heard from anyone that it did work without it.

@jonringer
Copy link
Contributor

hmm, actually I'm not sure anymore, I still seem to be getting crashes

@raboof
Copy link
Member Author

raboof commented Sep 7, 2020

hmm, actually I'm not sure anymore, I still seem to be getting crashes

Hmm, I can't reproduce those yet. Is there anything in particular that you do to trigger them?

Do you also get them on 6.3?

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/glx-not-recognised-after-mesa-update/6753/11

@raboof
Copy link
Member Author

raboof commented Oct 19, 2020

/marvin opt-in
/status needs_reviewer

@marvin-mk2 marvin-mk2 bot added the marvin label Oct 19, 2020
@marvin-mk2
Copy link

marvin-mk2 bot commented Oct 19, 2020

Hi! I'm an experimental bot. My goal is to guide this PR through its stages, hopefully ending with a merge. You can read up on the usage here.

@vikanezrimaya
Copy link
Member

vika@primrose ~ $ result/bin/sweethome3d
libGL error: MESA-LOADER: failed to open radeonsi (search paths /run/opengl-driver/lib/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /run/opengl-driver/lib/dri)
libGL error: failed to load driver: swrast
libGL error: MESA-LOADER: failed to open radeonsi (search paths /run/opengl-driver/lib/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /run/opengl-driver/lib/dri)
libGL error: failed to load driver: swrast
Caught handled GLException: X11GLXDrawableFactory - Could not initialize shared resources for X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x0, owner false, ResourceToolkitLock[obj 0x34a50970, isOwner false, <319eedc7, 379a2121>[count 0, qsz 0, owner <NULL>]]] on thread main-SharedResourceRunner
    [0]: jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:306)
    [1]: jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353)
    [2]: java.lang.Thread.run(Thread.java:748)
Caused[0] by GLException: main-SharedResourceRunner: Unable to create temp OpenGL context(1) on thread main-SharedResourceRunner
    [0]: jogamp.opengl.x11.glx.X11GLXContext.createImpl(X11GLXContext.java:390)
    [1]: jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:765)
    [2]: jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:648)
    [3]: jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:586)
    [4]: jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:277)
    [5]: jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353)
    [6]: java.lang.Thread.run(Thread.java:748)
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.eteks.sweethome3d.SweetHome3DBootstrap.main(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
	at javax.media.j3d.GraphicsConfigTemplate3D.isGraphicsConfigSupported(GraphicsConfigTemplate3D.java:348)
	at com.eteks.sweethome3d.j3d.Component3DManager.createGraphicsConfigurationTemplate3D(Unknown Source)
	at com.eteks.sweethome3d.j3d.Component3DManager.<init>(Unknown Source)
	at com.eteks.sweethome3d.j3d.Component3DManager.getInstance(Unknown Source)
	at com.eteks.sweethome3d.SweetHome3D.addComponent3DRenderingErrorObserver(Unknown Source)
	at com.eteks.sweethome3d.SweetHome3D.init(Unknown Source)
	at com.eteks.sweethome3d.SweetHome3D.main(Unknown Source)
	... 5 more
Caused by: com.jogamp.opengl.GLException: Profiles [GL4bc, GL3bc, GL2, GLES1] not available on device null
	at com.jogamp.opengl.GLProfile.get(GLProfile.java:1039)
	at com.jogamp.opengl.GLProfile.get(GLProfile.java:1050)
	at com.jogamp.opengl.GLProfile.getMaxFixedFunc(GLProfile.java:803)
	at javax.media.j3d.JoglPipeline.initialize(JoglPipeline.java:131)
	at javax.media.j3d.Pipeline.createPipeline(Pipeline.java:92)
	at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:858)
	at javax.media.j3d.VirtualUniverse.<clinit>(VirtualUniverse.java:267)
	... 12 more
^C
X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 1/1, reusable (open, marked uncloseable): 0, pending (open in creation order): 1)
X11Util: Open X11 Display Connections: 1
X11Util: Open[0]: NamedX11Display[:0, 0x7fe83c000e30, refCount 1, unCloseable false]

is this normal? Not reproducible under github:NixOS/nixpkgs/a371c1071161104d329f6a85d922fd92b7cbab63 with 6.3

@raboof
Copy link
Member Author

raboof commented Nov 16, 2020

is this normal?

Hmm no that doesn't look good of course ;)

I can't reproduce this with nix-review pr 97129 though - how did you build it here?

@vikanezrimaya
Copy link
Member

nix build github:raboof/nixpkgs/sweethome3d-6.3-to-6.4.2#sweethome3d.application - don't forget to enable flakes, or it would barf

@raboof
Copy link
Member Author

raboof commented Nov 17, 2020

nix build github:raboof/nixpkgs/sweethome3d-6.3-to-6.4.2#sweethome3d.application

I'm sorry, I haven't worked with flakes before, how do I run the result of this build?

I rebased this branch, but running nix build github:raboof/nixpkgs/sweethome3d-6.3-to-6.4.2#sweethome3d.application does not seem to rebuild the application again.

@vikanezrimaya
Copy link
Member

Pass --refresh to nix build to ensure it always downloads the fresh tarball. The result of the build is placed under a result symlink in the current working directory, as with the older nix-build.

@vikanezrimaya
Copy link
Member

To be honest, I'm just using Nix flakes because it makes pulling random branches easier with just one command to build a derivation instead of pulling a PR into a local checkout and then building it.

@raboof
Copy link
Member Author

raboof commented Nov 17, 2020

Pass --refresh to nix build to ensure it always downloads the fresh tarball. The result of the build is placed under a result symlink in the current working directory, as with the older nix-build.

Gotcha!

After rebasing I don't see the stack trace you're showing above. Could you see if you still get it?

Unfortunately IIRC the opengl libraries can introduce some impurity (i.e. https://discourse.nixos.org/t/why-opengl-drivers-userspace-libraries-are-installed-as-system-profile-dependencies-not-application-dependencies/1863)

@vikanezrimaya
Copy link
Member

Oh, wait, I can't reproduce it either now. Issue dismissed.

/status needs_merger

Copy link
Member

@timokau timokau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@timokau timokau merged commit 5715535 into NixOS:master Nov 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants