NVIDIA Announces The Jetson TX2, Powered By NVIDIA's "Denver 2" CPU & Pascal Graphics

[L_A_G]

It is causing real problems for developers:

You seems like didn't compute last time, so once again:With knowing that nVidia GPU drivers is fail OpenGL conformance tests and causing problems to developers, do you care enough to maybe correct your sentence about OpenGL drivers comparsion?

Once again, you're quoting some random anonymous person on the internet. You may find this hard to understand, but because of it, this person has absolutely no credibility as there is no way to verify they're not making it all up.

Turns out there is no OpenCL on Tegra, so full-blown vendor lock-in.

Also makes this discussion about OpenGL driver conformance even more pointless...

Let's see... do you see 4.4 here? Or maybe here? Nope.

You don't see the kernel version mentioned in any of those and it's not like Android works without a kernel...

Seriously thou, it really should at least try to look things up because this is the first result to a Google search for "android 7 kernel version".

I actually hopes that nVidia will stop abandoning their embedded hardware. But they done this before with every generation, and I don't see evidence that anything changed with X1 or will change with X2.

Seeing how you're declaring something that received some major updates only last November "dead" because Nvidia hasn't shipped it with the same kernel as two other devices using the same SoC and it's successor you're either being way too hasty or then you're just spreading good old fashion Microsoft style FUD.

You finally doing your homework as I see, however, there is no mainline kernel that can completely bring up actual X1-based hardware that people have on hands and moreover - graphics driver updating is stopped anyway which proves my original point.

No mainline support? You sure could have fooled me...

Once again, at least try to look things up to see if they're true before you use them as arguments.

Oh and before you try to move the goal posts by getting anal about the details, here's someone building mainline 4.4 for the TK1. The TK1's entry in the Embedded Linux Wiki should spread some further light on the use of the TK1 without the Nvidia provided build.

As for the drivers, you do know that Nvidia has several branches of their drivers in active development? Even for the same OS. A quick Google search for the version in the latest driver package for the TK1 (362.24.18.0) finds nothing except the latest toolkit update for the TK1 proving that this really is a new version of the 362 branch for the TK1.

The fact that Nvidia hasn't ported some other branch to the TK1 doesn't mean that they've abandoned driver development for it. So stop with the FUD already.

With your examples you just showed how miserable situation with MIPS and ARM embedded ecosystem.

You asked for embedded examples and then declared that those don't apply to AMD's embedded stuff. Sorry to break this to you, but embedded is not like desktop regardless if you're running the same architecture as the development systems you're using. You're still going to need the embedded toolkit for development and specially debug purposes regardless if you're running x86 or ARM.

Because you doesn't need my arguments to understand that for example toolchain situation is different between x86 and MIPS&ARM-boards world. I mean, you perfectly know that without me, but still insist that this could be similar issue with AMD SoC. Same with every other your example, which is, as you perfectly know, doesn't make sense for AMD SoC.

I get the feeling you have no experience doing embedded work and are just assuming that desktop development is completely the same. The reality is that doing embedded development adds quite a bit of additional hassles into the mix and additional tools you're not going to need when you're actually running the actual product on your own machine.

Or if it planned obsolescence by newer hardware generation, like it always happening with Tegra.

Again with the FUD... The fact that they haven't shipped something with a recent kernel really doesn't really mean much when the last major toolkit update for the hardware was only a few months ago and you can compile your own kernel from mainline.

Instead of designing own boards/modules, yes. But this is unrelated to fact that issues with nVidia drivers can be fixed only by nVidia. In case of AMD, if issue somehow is overlooked by AMD and by community, there is other ways, while with nVidia it's dead end, because there is no sources.

For the people who actually buy these off-the-shelf solutions it's a dead end on AMD APUs as well as they have neither the budget to hire someone to fix the problems for them or the required expertise in-house to fix it themselves. Let's not forget that AMD's software teams have gone trough some rather major layoffs in the last few years and I'm not sure if they even have more than a couple of dozen people dedicated to their Linux efforts altogether.

We are talking about toolkit here. Try again.

You spoke about drivers and toolkit, not toolkit exclusively. As for tookits, Nvidia has the same toolkits for HPC, regular desktop compute and embedded compute (i.e stuff like this).

The point about AMD sharing drivers and toolkit between platforms/uses is a moot one when Nvidia does the same thing.

[RussianNeuroMancer]

You may find this hard to understand

You know that driver is not following OpenGL specification, you know that something that has been developed against NvidiaGL implementation is having hard time running on OpenGL implementations (that what you call "how much better Nvidia's drivers perform in OpenGL", while it's not exactly OpenGL, which eventually make big difference for end users opinion as you can see on your own example). So hard to do the 1+1 math?

Also makes this discussion about OpenGL driver conformance even more pointless...

It was pointless, but only until your "how much better Nvidia's drivers perform in OpenGL" statement that was made without understanding whole picture with OpenGL implementations, and issues of this implementations.

You don't see the kernel version mentioned in any of those and it's not like Android works without a kernel...

This is source code of Shield TV and Pixel C firmwares. There is no Linux 4.4 is Android 7.1.1 firmware for Pixel C and no Linux 4.4 in Shield TV Software Upgrade 5.1.0, yet somehow this firmwares works. Obviously, because there is other kernels in this firmwares, but not 4.4.

No mainline support? You sure could have fooled me...

They keep adding X1 hardware support around 4.10 as far I remember, so it's not fully works AFAIK. If they are going to finish this - of course, it will be very respectable move. However still no signs of Pixel C or CB5-311 support, nothing above 362 on graphics side.
Also all previous Tegra generations remain dropped (I would love to get some Tegra 3/4-based devices on hands to see how it works with modern software, but nVIdia decided "nope"; even CB5-311 is no-go right now).

Once again, at least try to look things up to see if they're true before you use them as arguments.

Like you talking about Linux 4.4 in Pixel C firmware while there is other release in Android 7.1.1 sources of Pixel C firmware? And, while there is other release, you saying "it's not like Android works without a kernel..." joking, again?

As for the drivers, you do know that Nvidia has several branches of their drivers in active development?

Yes, that why 304 branch still tear as hell because V-Sync with KWin and Compiz was fixed around 340. That means no any fixes from newer branches for 362 branch, besides maybe DDX updates, like with 304.

You're still going to need the embedded toolkit for development and specially debug purposes regardless if you're running x86 or ARM.

For what on x86? Doesn't need to generate special toolchain, or rootfs, pick up packages, or use special debugging software - all of this can be done with regular tools.

I get the feeling you have no experience doing embedded work and are just assuming that desktop development is completely the same.

Not like you, I know from experience that paradigm you are used to with MIPS and ARM not applicable to boards with AMD SoC (well, you could apply it, if you want it badly, but you doesn't need to do this, because there is no issues/limitation that you have with most of MIPS and ARM boards; AMD SoC is much easier to deal with) or few boards with Intel SoC that I working with for last year. I have to note that AMD SoC is easier even in comparison with Intel - there was nothing from Intel between 3.10 and 4.9 for some boards, and 4.9 is still far from being finished (in 4.9 there is still no Intel Atom ISP driver, Intel LPSS PWM controller driver currently simply not working on some boards, X-Power AXP288 PMIC driver maybe will get in shape for ACPI around 4.12 or so, but if Intel is going to backport this into 4.9 is mystery to me; etc.)

you can compile your own kernel from mainline

nVidia still adding hardware support in 4.10 for one board (nothing about others, like CB5-311 and Pixel C). How do you know they finished even for one board?

Let's not forget that AMD's software teams have gone trough some rather major layoffs in the last few years and I'm not sure if they even have more than a couple of dozen people dedicated to their Linux efforts altogether.

Three dozens only for AMDGPU kernel module, not talking about everything else, like CPUs, compilers, Mesa, HSA... Anyway, for everything else you can grep kernel, Mesa, gcc, llvm and other sources for e-mails.

For the people who actually buy these off-the-shelf solutions

It's not people I talking about in paragraph one.

it's a dead end on AMD APUs as well as they have neither the budget to hire someone to fix the problems for them or the required expertise in-house to fix it themselves.

Only if issue is not fixed by AMD and by community. While in nVidia case there is only nVidia.

As for tookits, Nvidia has the same toolkits for HPC, regular desktop compute and embedded compute (i.e stuff like this).

Same toolkit for compiling to ARM target? Or same embedded toolkit? Check again what we talking about on previous page - last paragraph.