New Jetson....

[Brian Beuken]

hmm very curious, if I try to run from VisualGDB I get no XWindow
but if I run it from a terminal on the jetson...thar she blows...no idea of framerate due to lack of debugger..but very fast and smooth as you might expect, thugh still a little judder on turns with lots of models...more likley thats CPU bound though as the code is not optimised at all.

This appears to be a VisualGDB issue so I've contacted Sysprogs and will see what they can tell me

[jomoengineer]

Very cool. I'm glad you finally got on in hand. Have you posted the bits for the tests you are running on this?

[Brian Beuken]

bits?
I just use my standard (and needing a bit of a revamp) 3D made demo which pushes obj, md2 and physics sysytems. Most SBC's even the lowly NanoPi M1's can run it, from 30fps up.. a good system should comfortably manage 60fps.

Its a very exciting machine, and will be great to demonstrate the advantages of transferring processing to the GPU, with 128 cores as opposed to the usual 2-4, (6 on an XU4) it just leaves everything else behind. While still having a fairly standard low power (but high for an SBC) ARM CPU.

Exciting machine....but need to work out this odd XDisplay issue, thats stopping things...going to build hello triangle for standard linux (I only have raspberry versions of the simpler files) and see what happens.

[Brian Beuken]

Yeah I can confirm all the OpenGLES3.0 book examples compile and run on the target using Cmake (I had to install cmake) which is nice, it shows indeed that its fully compliant, I just need to get some of them working from my PC using VisualGDB or VS4Linux and put it through its paces.
Very busy now for a few days, so am going to have to put it away (awww) and come back to it this weekend.

Sysprogs are adamant its not a VisualGDB issue, though I have my doubts, but will need a day to play with it and have too many other things on just now.

[Brian Beuken]

Do me a favour Jomoengineer, can you try and execute a graphic program (the OpenGLES3.0 demos) for example from another machne via ssh.

Im pretty sure most of them will also fail to open a display window and cause a seg error... but let me know..

[Brian Beuken]

Still struggling to get my dev based system to work on this, no attempt from a client to execute a graphics program works, XOpenDisplay just won't work unless you open it from a native terminal... But while debugging and running direct is out, I can still build and run things on it as a stand along unit, and I have to say...wow

just wow... This isn't just a beast, its a Godzilla of a beast, when dealing with all the usual pitfalls of a slow CPU and getting the GPU to do the bulk of its work..it rips through every high level demos I have, even some written for PC based OpenGLES3.2 systems, and Vulkan.. its extaordinary. Throwing frame rate scores 10-20 times better than the best SBC's (assuming they could even run ES3.2 or Vulkan)
Not surprising considering this is basically half a Nintendo Switch, same GPU but half the number of GPU cores, and perhaps a little less custom silicon.

Of course this system is not a mainsteam unit, its a test system built by Nvida to encourage developers to improve and develop software for AI and other systems, the fact it has a Tegra video chip is just a big bonus for graphic tinkerers like me. It must cost them much more to make than they sell it for, but if it ever did go into mass production it would probably not suit everyone. Its not a general SBC like the Raspberry clones, this is a specialist system which though capable of doing maker stuff is best left to dreamers like me who just want to see what small systems can do.

If a phone were to use a chip like this it would guzzle batteries and run so hot it would be impossible to handle, so it breaks the general rules of low power, low heat, and probably reliability.


Can't wait to try more things on it, but for now it goes in the drawer until I find a resolution to the XOpenDisplay issues. Which I am sure will come, I'm pretty sure its going to be a simple answer that someone much smarter than I will work out.

[Brian Beuken]

found it.

I figured it had to be something to do with access rights somewhere, so I went to the settings and checked the Securty and Privacy->Password settings. I didn't see anything odd there, but while I was in I switched to autolog on.

Guess what.. that solves it.. My projects now happily build and run and can be executed from my VisualGDB debug command.

To double check I set autologin back to off and sure enough my VisualGDB failed again

So the secret is... ensure you have automatic login, with your matching ssh username

Bizzare issue...Dunno why this is happening, but very happy I resolved it.

[Brian Beuken]

And now that I have a working system, some interesting things are happening, there is actually quite a lot of stutter and frame drop which I didn't expect...maybe some of it is due to sending data back to GDB, but I suspect its more to do with my really bad designed code. I will investigate soon.

[jomoengineer]

Brian,

Sorry, I missed you request a few moons back.

How were you able to solve getting an OpenGL EX 3.x example to work over SSH.  I can get it to run on a separate screen attached to the Nano, but not within an ssh session.  I had to do 'export DISPLAY=:0' to get it to display on the other screen on the Nano.

Also, do you use glmark2 as a demo.   Do you have any demo code that works with the Nano?

Thanks,

Jon

[Brian Beuken]

its entierly down to the access rights, if you have auto log in, its all good....

Don't ask me why, I'm sure its more linux voodoo paranoia with access but since setting it to auto the Jetson has been good as gold

And ye I do use glmark2 as much as I can, on Ubuntu systems usually just apt-get install works, but Debian needs to build it, I follow these instructions

https://www.pcsuggest.com/install-glmark2-debian/

Just remember you're building GLmark2-es2 so use glesv2 as a flavour which will generate glmark2-es2 rather than glmark2