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

[RussianNeuroMancer]

Because you still haven't come forward with anything more substantial than a post by some anonymous person on the internet.

Google for "piglit pass fail skip nvidia". As for me - after struggling with nVidia hardware for few years, I was happy to find that other vendors is much easier to deal with. Maybe you'll try AMD SoC someday, and find the same.

Muh OpenCL!!!1

You still don't get that this is not about OpenCL.

Did you actually read the Jetpack 3.0 announcement or are again acting as if Nvidia's in-house GPU driver is distributed the same way as AMDGPU? Because the Jetpack 3.0 announcement specifically says that they're continuing to support the TK1 with all the same API versions as the new TK2, including CUDA 8, which is the latest version of the API.

Even read release notes of L4T 24.2.1 (which is X1's L4T release in JetPack 3.0) where it specifically says that version of binary driver is 362, that is almost one year old (nVidia as usually drop legacy hardware, like with 304 series). Funny thing that you didn't read it, and still trying to prove something, like drivers compatibility with Linux 4+ (which is non-existent for X1).

That why it's so great that if you want newer drivers for Tegra - you have to stop using what you have and order a batch of newer one.

Seeing how you didn't understand that it was a joke

So, instead of addressing real issue try to say something finny once again.

You didn't even use some random anonymous person on the internet, you just speculated that it won't work when their desktop Linux driver, which is almost completely the same code, doesn't have any problems with different kernels due to having minimal interaction with the kernel.

It does not work right now. If you doesn't know current situation with Tegra drivers - it's your problem, not mine.

The reality is that AMD R-Series APUs and most ARM-based SoCs really aren't different paradigms in terms of developer support.

And then you trying to apply what is known for you to vendor that is completely different:

Really? Care to provide some actual evidence that AMD will provide free direct support to anyone who buys a board with one of their APUs? Because I'm pretty sure you have to set up a contract with them for them to provide support for something they didn't sell you (at least directly).

If you design board around their SoC - then you already have contract. For everything else (including cases when board bought from partner) there is kernel.org and freedesktop.org bugtrackers (because things like kernel drivers, toolchain bits (including Clang 3.9 and 4.0, GCC 6.3 and 7.0, various debuggers, CodeXL, and more) OpenGL 4.5, VA-API for H.264/H.265/VP8/VP9, etc. - in upstream, right now) and regular technical support for hybrid driver, if you need this driver.

[L_A_G]

Google for "piglit pass fail skip nvidia". As for me - after struggling with nVidia hardware for few years, I was happy to find that other vendors is much easier to deal with. Maybe you'll try AMD SoC someday, and find the same.

If failing conformance tests was such a massive issue, why do most games still run fine, if not better on Nvidia hardware? You're placing just way too much weight on your conformance tests. Even if this was an issue, you should remember that the much important thing here is CUDA and OpenCL compatibility as these are meant to run real time compute applications, not games.

You still don't get that this is not about OpenCL.

I'm going to disagree with you seeing how your whole argument is basically one big ball of FUD.

Even read release notes of L4T 24.2.1 (which is X1's L4T release in JetPack 3.0) where it specifically says that version of binary driver is 362, that is almost one year old (nVidia as usually drop legacy hardware, like with 304 series). Funny thing that you didn't read it, and still trying to prove something, like drivers compatibility with Linux 4+ (which is non-existent for X1).

Again with the FUD? How many times do I have to remind you that Nvidia's GPU drivers are pretty indifferent to whatever kernel version you're running because of the way they're built. If desktop 362 runs just fine with 4.X kernels, then I really can't see any valid reason why their embedded drivers, which as I said are derived from the same code base, would be any different.

So, instead of addressing real issue try to say something finny once again.

It's not my problem if you're so suck up that you can't take a joke. Maybe you should leave the keyboard once in a while and go outside?

It does not work right now. If you doesn't know current situation with Tegra drivers - it's your problem, not mine.

The fact that it doesn't ship with a 4.X version kernel doesn't mean that it doesn't work. We're not talking about a completely separate code base here with loads of things that are so sensitive they stop working if you even breathe on them. Nvidia's embedded drivers are pretty much the same as their Linux desktop drivers with the difference that they've got a few things for ARM.

And then you trying to apply what is known for you to vendor that is completely different:

I gave you an example out of my personal experience when you demanded one and now because it's with a different vendor it's somehow not valid. Are you so desperate that you've started moving goalposts thinking I wouldn't notice?

If you design board around their SoC - then you already have contract. For everything else (including cases when board bought from partner) there is kernel.org and freedesktop.org bugtrackers (because things like kernel drivers, toolchain bits (including Clang 3.9 and 4.0, GCC 6.3 and 7.0, various debuggers, CodeXL, and more) OpenGL 4.5, VA-API for H.264/H.265/VP8/VP9, etc. - in upstream, right now) and regular technical support for hybrid driver, if you need this driver.

If you've ever designed and built your own hardware you'd know that it's both expensive, time consuming and requires resources most companies just don't have on hand unless they're in the hardware business themselves. You'd be surprised how expensive a 14 layer PCB is to manufacture in small volumes. Even if you can hire another company to design and manufacture the hardware for you, the problem with support is not going to be the exact same as when you buy a board built by a partner company.

Also the fact that development of a lot of AMD-related drivers and tools is done in the open doesn't mean that you're going to get any real support from these developers. The only difference is that you essentially get to go in and fix other people's mistakes rather than having the people who made those mistakes fixed for you when you find them.

[nomadewolf]

The Pixel C doesn't have ChromeOS, it has Android, which is the only reason I didn't buy it.

Why do you prefer ChromeOS over Android?
True you get that Destop feeling, but it's nothing more than a feeling...
Android's UI is not good for Desktop like setups, but at least is a way more powerfull OS.

[RussianNeuroMancer]

If failing conformance tests was such a massive issue

So we get over the fact that nVidia drivers fail with OpenGL conformance more than, for example, Mesa. Finally.

You're placing just way too much weight on your conformance tests.

OpenGL have specification and Khronos Group behind it, NvidiaGL - doesn't. API that have proper specification is better, obviously. Now it's will be finny if you begin defend nVidia's out-of-spec undefined behaviour. Oh, my, you already doing that...

seeing how your whole argument is basically one big ball of FUD

Call it whatever you want, the point is - this is not about OpenCL.

Again with the FUD?

JetPack 3.0 release notes is FUD now, VERY BIG OKAY.

If desktop 362 runs just fine with 4.X kernels

Brilliant... there is no "desktop 362".

I really can't see any valid reason why their embedded drivers, which as I said are derived from the same code base, would be any different

It is different. Why? I have no idea - ask nVidia.

instead of addressing real issue try to say something finny once again

Maybe you should leave the keyboard once in a while and go outside?

Lol, you are obedient, but no - this one is not funny. I'll let you try again. (And you, as expected, will stop joking.)

The fact that it doesn't ship with a 4.X version kernel doesn't mean that it doesn't work. We're not talking about a completely separate code base here with loads of things that are so sensitive they stop working if you even breathe on them. Nvidia's embedded drivers are pretty much the same as their Linux desktop drivers with the difference that they've got a few things for ARM.

Except there is nothing above 3.10.96 from nVidia for X1 and nothing above 362 driver for X1, because nVidia as usually drop support for older Tegra, as soon as there is newer one, so "you really can't see valid reason" and stuff, but let's stick to what is actually available for X1, not to something imaginary that, could (but never will) be available.

I gave you an example out of my personal experience when you demanded one

I couldn't care less for your personal experience and never asked about it. I asked for example that will make sense for AMD SoC, and you failed to deliver even just one.

Also the fact that development of a lot of AMD-related drivers and tools is done in the open doesn't mean that you're going to get any real support from these developers. The only difference is that you essentially get to go in and fix other people's mistakes rather than having the people who made those mistakes fixed for you when you find them.

No vendor fix 100% reported issues, including nVidia. Do you admit that? If your answer is "yes" then go to the last paragraph.

[L_A_G]

So we get over the fact that nVidia drivers fail with OpenGL conformance more than, for example Mesa. Finally.

I mean really... You're basing your stance on an academic conformance suite and I'm basing my stance on actual real world use of the drivers. Also, the whole argument is more than just a bit silly when we're talking about something that isn't even made for being used to run real time graphics applications like games. This is a bit like comparing how well a couple of compact cars do at off-roading.

Call it whatever you want, the point is - this is not about OpenCL.

No, it's about you going on as if Nvidia is going to kill support for their older hardware at the drop of a hat and how Nvidia's drivers supposedly aren't going to work with anything except the kernel version they were shipped with as if every version of the kernel came with sweeping changes to the DRM subsystem.

JetPack 3.0 release notes is FUD now, VERY BIG OKAY.

The FUD isn't in the actual release notes, but the hallucinations you're having over the default kernel image being a bit on the older side.

Brilliant... there is no "desktop 362".

Oh really... Oh and before you talk about how this is a Windows driver, if you actually read the link you'll see that the 362 driver is a further development of the 361 drivers, which are available on Linux.

It is different. Why? I have no idea - ask nVidia.

It somehow being different was your argument, not mine.

Lol, you are obedient, but no - this one is not funny. I'll let you try again. (And you, as expected, will stop joking.)

Oh great... You're one "Allahu Open souce!!! *KABOOM*" types who read Defective by Design like Abu Bakr al-Baghdadi reads the koran...

[QUOTE]Except there is nothing above 3.10.96 from nVidia for X1 and nothing above 362 driver for X1, because nVidia as usually drop support for older Tegra, as soon as there is newer one, so "you really can't see valid reason" and stuff, but let's stick to what is actually available for X1, not to something imaginary that, could (but never will) be available.

How many times do I have to remind you that Nvidia's linux drivers have for a long time been very kernel neutral? How hard can it be to understand something this simple because I'm starting to run out of patience repeating the same point over and over again. I'm also going to have to point out that the Nvidia Shield TV, which uses the same K1 SoC, got an update to Android 7.0 a month ago and that runs kernel 4.4 so not only should it be easy to do the update yourself, but Nvidia can still do that themselves.

I couldn't care less for your personal experience and never asked about it. I asked for example that will make sense for AMD SoC, and you failed to deliver even just one.

First you ask for examples, then I give you ones from my personal experiences (so they aren't hearsay) and now you moan about how it doesn't matter because it's not about an AMD SoC specifically as if AMD's SoCs were pooped out by unicorns and thus somehow completely different from all other SoCs on the market.

No vendor fix 100% reported issues, including nVidia. Do you admit that? If your answer is "yes" then go to the last paragraph.

The fact that no vendor fixes 100% of software bugs really doesn't matter when no open source project does the same and you're not necessarily going to have the time, skills or resources yourself to fix whatever the vendor or the open source code community can't or won't fix. As hard as you'd like to believe it, not every company is like Valve or Collabora with loads of resources to go out and fix broken things in other peoples' work.

If you're going with a SoM or a partner board to begin with you're obviously not going to have large amounts of developer resources to spend debugging and fixing the toolkit, the drivers or the hardware you're using. This may be relevant if you're building your own hardware and can afford an overhead-heavy development process, but most companies these days try to minimize overhead and use off-the-shelf solutions as much as possible.

[AndyChow]

Why do you prefer ChromeOS over Android?
True you get that Destop feeling, but it's nothing more than a feeling...
Android's UI is not good for Desktop like setups, but at least is a way more powerfull OS.

ChromeOS = absolutely nothing superfluous. It's much leaner than Android, faster, distraction free. It also used to have native SSH, which unfortunately they removed. Now you can add it with a chrome plugin, but it's just not the same.

Also, Chrome on Android isn't as good as Chrome in ChromeOS.

With a laptop, I just want it to have Chrome, SSH, and be fast. That's my usecase. My laptop needs aren't my desktop needs.

[RussianNeuroMancer]

I mean really... You're basing your stance on an academic conformance suite

My argument about undefined out-of-spec behaviour still stand, so get over it. An you honestly expect them to follow for example OpenCL spec while they shitting on OpenGL spec?

it's about you going on as if Nvidia is going to kill support for their older hardware at the drop of a hat

Which is already happened with X1.

The FUD isn't in the actual release notes, but the hallucinations you're having over the default kernel image being a bit on the older side.

Go on, show another kernel for X1 that can bring up TX1 or CB5-311.

Oh and before you talk about how this is a Windows driver

And you dare to talking about hallucinations...

if you actually read the link you'll see that the 362 driver is a further development of the 361 drivers, which are available on Linux

There is no 362 deskop driver, and only 362 driver for X1, that it.

Oh great... You're one "Allahu Open souce!!! *KABOOM*" types who read Defective by Design like Abu Bakr al-Baghdadi reads the koran...

Your jokes get worse with every attempt.

How many times do I have to remind you that Nvidia's linux drivers have for a long time been very kernel neutral?

SoC need not only GPU driver, you know.

so not only should it be easy to do the update yourself

If it's so easy where is this newer kernel for actual board? And of course newer GPU driver that is compatible with this kernel.

First you ask for examples, then I give you ones from my personal experiences (so they aren't hearsay) and now you moan about how it doesn't matter because it's not about an AMD SoC specifically as if AMD's SoCs were pooped out by unicorns and thus somehow completely different from all other SoCs on the market.

There is no point in your stories about issues in Xilinx's documentation, quest for working toolchain or something like that in AMD SoC context - because there is no such issues (like issues you get with MIPS and ARM boards) in first place.

The fact that no vendor fixes 100% of software bugs really doesn't matter

Drivers bugs.

you're not necessarily going to have the time, skills or resources yourself to fix whatever the vendor or the open source code community can't or won't fix. As hard as you'd like to believe it, not every company is like Valve or Collabora with loads of resources to go out and fix broken things in other peoples' work.

Seems like you didn't get why I mentioned companies like Collabora in first place - because you can pay them for fix.

you're obviously not going to have large amounts of developer resources to spend debugging and fixing the toolkit, the drivers or the hardware you're using

With AMD SoC, that share toolkit and drivers code with their server/workstation/consumer hardware, what kind of bugs, that will be ignored by AMD and open source community, you expect to discover?

[L_A_G]

My argument about undefined out-of-spec behaviour still stand, so get over it.

It may have mattered if it was out-of-spec behaviour that was actually causing real problems or if we were talking about something that actually involved doing real time graphics. As it stands, complaining about harmless out-of-spec OpenGL performance is basically like complaining about pedestrians not waiting for traffic lights when they can see the lights turning to red for motorists.

An you honestly expect them to follow for example OpenCL spec while they shitting on OpenGL spec?

So far I haven't seen anyone talk about out-of-spec OpenCL behaviour and when I did my Master's Thesis project, which was an OpenCL application I developed ran almost exclusively on Nvidia hardware, I never ran into any out-of-spec behaviour. All you really seem to have on this topic is good old fashion Microsoft style FUD...

Which is already happened with X1.

Really? Because the X1 when used in the Shield TV and Pixel C have both gotten official updates to Android 7, which uses kernel version 4.4. If you mean the TX1, then the last toolkit update it got was only a few months ago and the latest documents in relation to it are only a week old, so it's a bit early do declare it to abandoned. Then again this does fall pretty well in line with the way most of your arguments have all really been Microsoft style FUD.

Go on, show another kernel for X1 that can bring up TX1 or CB5-311.

It's not like I've got a TX1 on hand to show you a running 4.X kernel, but if the other devices I just mentioned using the same SoC are anything to go by, then kernel version 4.4 and newer should work just fine. Let's not forget that Nintendo chose the X1 as the SoC of choice for the Switch and uses their driver back end on it so Nvidia is pretty heavily incentivised to continue further developing it for the X1.

And you dare to talking about hallucinations...

So are you saying Windows doesn't exist and that they use the same numbering scheme to confuse people?

There is no 362 deskop driver, and only 362 driver for X1, that it.

Didn't I just point you towards a 362 desktop Windows driver and Nvidia documentation saying that there really isn't such a thing as a 362 driver, there's just further developed 361?

Your jokes get worse with every attempt.

It's not like you've got much of a sense of humor the way you completely missed the first one and thought it was me being angry.

SoC need not only GPU driver, you know.

Sure, but we're talking bog standard stuff that's been supported in the mainline kernel for quite a while.

If it's so easy where is this newer kernel for actual board? And of course newer GPU driver that is compatible with this kernel.

I wouldn't be the least bit surprised if they kept it the way it is right now to avoid breaking end user applications. If end users want newer kernel versions then they're free to risk breaking them and can compile their own kernel as Nvidia has the necessary files available to everyone who's interested on their own website. If they didn't want people compiling their own kernels for the TK1, do you really think they'd put up the all the necessary files on their website?

There is no point in your stories about issues in Xilinx's documentation, quest for working toolchain or something like that in AMD SoC context - because there is no such issues (like issues you get with MIPS and ARM boards) in first place.

You asked for examples where problems can occur and when I provided them you said that they're somehow not problems AMD's APUs can ever suffer from based on nothing. If you can actually motivate it using something more convincing than a "Nu-uh" then please do because you've gone several posts just repeating the same claim without evidence over and over again.

Drivers bugs.

Yes, they exist and they're not always fixed, specially when hardware becomes obsolete in the eyes of the driver developers.

Seems like you didn't get why I mentioned companies like Collabora in first place - because you can pay them for fix.

Yes, another company you have to get to sign an agreement with and pay for support... You do realise that companies and people use SoMs and other "just add peripherals and application software" solutions to cut down on cost and time-to-market?

With AMD SoC, that share toolkit and drivers code with their server/workstation/consumer hardware, what kind of bugs, that will be ignored by AMD and open source community, you expect to discover?

What kind of bugs do you expect Nvidia not to fix when most of their driver code base is shared between servers, workstations, consumer desktops, laptops, mobile devices and a game console? Do I have to point you towards how much better Nvidia's drivers perform in OpenGL when compared to AMD's open and closed equivalents?

[liam]

Seeing how Volvo is actually using the predecessor to this for their completely functional self driving cars I'd beg to differ on that.

a completely functional self driving car exists? And if only needs 15W?!!!!!
Sold!

[RussianNeuroMancer]

It may have mattered if it was out-of-spec behaviour that was actually causing real problems or if we were talking about something that actually involved doing real time graphics.

It is causing real problems for developers:

Do I have to point you towards how much better Nvidia's drivers perform in OpenGL when compared to AMD's open and closed equivalents?

You seems like didn't compute last time, so once again:

You are behind the times, and should really be firing your complaints at Nvidia. For the last couple of years I've used ATI cards for GL development exclusively. Unlike Nvidia cards they actually implement the GL spec to the letter. With Nvidia cards you can pretty much call any old combination of GL functions, and something will appear on screen. They never fail! This is a problem because you never find out errors in your GL code until after you've shipped the product. With ATI, if you pass an invalid arg, or call a method at the wrong time, they will generate the correct error. This sadly leads to a situation where a developer uses an NVidia card for development, ships, and then it won't run on ATI or Intel cards. The upshot is that people incorrectly assume that ATI drivers suck. They don't. Nvidia drivers are the ones that suck!

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?

So far I haven't seen anyone talk about out-of-spec OpenCL behaviour and when I did my Master's Thesis project, which was an OpenCL application I developed ran almost exclusively on Nvidia hardware, I never ran into any out-of-spec behaviour.

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

If end users want newer kernel versions then they're free to risk breaking them and can compile their own kernel as Nvidia has the necessary files available to everyone who's interested on their own website.

Really? Because the X1 when used in the Shield TV and Pixel C have both gotten official updates to Android 7, which uses kernel version 4.4.

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

Let's not forget that Nintendo chose the X1 as the SoC of choice for the Switch and uses their driver back end on it so Nvidia is pretty heavily incentivised to continue further developing it for the X1.

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.

Sure, but we're talking bog standard stuff that's been supported in the mainline kernel for quite a while.

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.

You asked for examples where problems can occur

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

you said that they're somehow not problems AMD's APUs can ever suffer from based on nothing.

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.

Yes, they exist and they're not always fixed, specially when hardware becomes obsolete in the eyes of the driver developers.

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

You do realise that companies and people use SoMs and other "just add peripherals and application software" solutions to cut down on cost and time-to-market?

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.

you're obviously not going to have large amounts of developer resources to spend debugging and fixing the toolkit, the drivers or the hardware you're using

With AMD SoC, that share toolkit and drivers code with their server/workstation/consumer hardware, what kind of bugs, that will be ignored by AMD and open source community, you expect to discover?

What kind of bugs do you expect Nvidia not to fix when most of their driver code base is shared between servers, workstations, consumer desktops, laptops, mobile devices and a game console?

We are talking about toolkit here. Try again.