Karpathy talk today at CVPR 2021

[mikes_fsd]

All I can say, is this is the same person that said 4D radar is like lidar and that Tesla was putting 4D radar on their cars.

The useful bit is the actual observation that they are using the HW3 processing power to run something.
I would venture it is actually maxing out on running a bunch of campaigns in shadow mode.
Karpathy specifically brought this up in the CVPR '21 talk how they were able to gather the data and run edge cases through to be able to release the first release of Tesla Vision sans radar.

The rest of his tweet is sensationalist speculation! He loves that sh!t.

 

[mikes_fsd]

The useful bit is the actual observation that they are using the HW3 processing power to run something.
I would venture it is actually maxing out on running a bunch of campaigns in shadow mode.

Just some context, the CVPR '21 slide above says that they ran the NN stack in shadow mode 7 times on a subset of the fleet before cutting the prudction release.

That means in parallel to the normal AP/FSD NN stack that was running on the car, they were running an entire NN stack for the Tesla Vision only.
Can anyone else see how that would spike the utilization of the HW3??!!


Now this is only to validate the Vision sans radar, they probably have other campaigns for different goals (FSD, NoA, bugs, etc)

Oh, this was mentioned elsewhere but worth repeating, there is probably little optimization that has been done on the current stacks - as they are working first to get features working. Tesla's acquisition of DeepScale should help with that once the time comes.

 

[Knightshade]

Yeah already discussed in several threads.

tl;dr- FSD is gonna need HW4 for better than L2, because the ability for 1 node to fail entirely and the system keep working is needed for better than L2.


The trick now is- can get they get there (without redundancy) using both nodes on HW3? If so then the allegedly 3x more powerful HW4 will be able to easily handle it WITH redundancy.

But if they run out of compute on HW3 without getting there, even using both nodes, then it remains unknown how much compute is needed.... which is problematic since now you don't know if HW4 is "enough" or not either and it's way too late to change its specs anyway.

All I can say, is this is the same person that said 4D radar is like lidar and that Tesla was putting 4D radar on their cars.

What he actually said is the firmware had another brand of radar added, which suggests Tesla planned to add that to the cars (otherwise why add it to firmware?)

You can read the whole thread with more context here.

https://twitter.com/x/status/1319363510980194306

In the end of course they didn't add that radar- they instead ditched all radar in new cars.

Possibly they decided vision was "close enough" already they didn't need the expense of changing vendors....or maybe the chip shortage caused supply issues as many have suggested.

Just some context, the CVPR '21 slide above says that they ran the NN stack in shadow mode 7 times on a subset of the fleet before cutting the prudction release.

That means in parallel to the normal AP/FSD NN stack that was running on the car, they were running an entire NN stack for the Tesla Vision only.
Can anyone else see how that would spike the utilization of the HW3??!!

Since greens "they are out of compute on a single node" observation is on the production release in his own vehicles (and has been observed since at least mid last year)-- no, I can't see that.

He sees what the car is running after all- including which NNs, and what shadow mode triggers are running too.

 

[mikes_fsd]

What he actually said

Yeah, keep reading the thread:

https://twitter.com/x/status/1319363515610812416

And he seems to be delusional enough to think that because he saw it in the firmware he somehow predicts its arrival in the actual fleet:

https://twitter.com/x/status/1319363517338759168

OH, and lastly, this was in a production firmware that was released to the fleet almost a year ago.
He makes the comment: "Anyway the in-house radar efforts appear to either be failing or too far behind the schedule/goals so Tesla apparently decided to buy a solution from an outside vendor again and their product certainly seems to be ticking all the requirement checkboxes."
Instead of the reality is that they shut down the in-house radar because they made the decision to focus on vision AT THAT TIME.

But then I would be speculating on that -- unless you look at May 2021 and see they actually remove the physical radar from the their best selling cars in NA market.

yes, he's such a wonderful source of analysis that green guy!

сопляк!

 

[Knightshade]

Yeah, keep reading the thread:

I did.

That's why I provided the link to it originally.

And he seems to be delusional enough to think that because he saw it in the firmware he somehow predicts its arrival in the actual fleet:

What other conclusion can you reach when Tesla adds firmware support for something?

Do you think they add support for hardware they have no intention of ever using?

Why would they do that? Why waste effort adding firmware support to something you're not interested in at all?

You seem to be ascribing "delusion" to the wrong person here.

 

[mikes_fsd]

What other conclusion can you reach when Tesla adds firmware support for something?

For many different reasons, but most simple one is to validate sh!t on a production build.

Why would they do that? Why waste effort adding firmware support to something you're not interested in at all?

Because, contrary to the ignorant belief that "tesla doesn't test sh!t" they actually do test their sh!t.

 

[mikes_fsd]

You seem to be ascribing "delusion" to the wrong person here.

Why, you want the title for yourself?
You can claim it also, there is no shortage of delusion in your posts.

 

[Knightshade]

Why, you want the title for yourself?
You can claim it also, there is no shortage of delusion in your posts.

I asked why you disagreed with the AHB required/not required being a bug since the two contradict each other- you had no answer at all.


I'm asking you why Tesla would add firmware support for a radar they never had any intention of using- you have no answer other than "to test on a production build" which makes zero sense.

First- the only way to test is if they PHYSICALLY INSTALLED THE RADAR.

Which is the thing you accused Green of being "delusional" for claiming they were doing.

(apart from which, testing on a development build that is otherwise identical, but not released to the public, would provide the SAME validation... the ONLY reason to include it in PRODUCTION builds is for PRODUCTION use- which is the intent Green correctly pointed out).

 

[mikes_fsd]

I asked why you disagreed with the AHB required/not required being a bug since the two contradict each other- you had no answer at all.

I think your rage has you confusing me with some other poster.
I did not engage you on the subject of AHB. please keep your head in the game:

 

[Knightshade]

I think your rage has you confusing me with some other poster.
I did not engage you on the subject of AHB. please keep your head in the game:
View attachment 679695

Uh, dude.

You disagreed with a -slew- of my posts before I began disagreeing with yours.

And ONE of the first of those disagrees was on a post about... AHB in the vision thread.

It's right here complete with your disagree still in place:

Tesla.com - "Transitioning to Tesla Vision"

I can't imagine relying solely on car sensors (vision, radar, or lidar, etc) in poor conditions. For me, if visibility isn't great, I'm always going to want to take more control of my vehicle, or not drive at all. Sure, even when I'm taking control, I want all the safety assistance I can get...

teslamotorsclub.com

Are you on something?

 

[mikes_fsd]

And ONE of the first of those disagrees was on a post about... AHB.

There is no discussion of AHB in this thread at all.

LMAO.. you are losing it.... or lost it:
@MP3Mike is not me and I am not @MP3Mike

please get back on the topic of this thread!

 

[mikes_fsd]

Do you have different people posting under your name on a per thread basis, such that one can't point out something you said in one thread versus another?

This is a prime example of the delusions that I was referring to upthread!

 

[Knightshade]

Sorry for the mixup, though somewhat understandable given you two are my entire recent disagree list, and both in the same two threads.

But let's go back to the other 95% of the post you decided to ignore in favor of that 5%


specifically-


I'm asking you why Tesla would add firmware support for a radar they never had any intention of using- you have no answer other than "to test on a production build" which makes zero sense.

First- the only way to test is if they PHYSICALLY INSTALLED THE RADAR.

Which is the thing you accused Green of being "delusional" for claiming they were doing.

(apart from which, testing on a development build that is otherwise identical, but not released to the public, would provide the SAME validation... the ONLY reason to include it in PRODUCTION builds is for PRODUCTION use- which is the intent Green correctly pointed out).



You keep calling Green "delusional" without being able to support the claim in any way.

He posted what the firmware showed, and pointed out the most likely reasons it showed that.

It remains the most likely, but then Tesla ended up not putting that HW into production.

Possibly it didn't end up performing well. Possibly they decided vision-only was close enough. Possibly it was a supply issue (as some have suggested that as a cause for pulling radar at all so soon).

But none of it is delusion.

 

[mikes_fsd]

First- the only way to test is if they PHYSICALLY INSTALLED THE RADAR.

Which is the thing you accused Green of being "delusional" for claiming they were doing.

(apart from which, testing on a development build that is otherwise identical, but not released to the public, would provide the SAME validation... the ONLY reason to include it in PRODUCTION builds is for PRODUCTION use- which is the intent Green correctly pointed out).

1 - real testing happens with real hardware! which requires real firmware
2 - false, what I called green delusional for is that seeing something in firmware somehow guarantees release to end user -- my exact quote: "And he seems to be delusional enough to think that because he saw it in the firmware he somehow predicts its arrival in the actual fleet"
we have seen plenty of times that PRODUCTION firmware has different NN's in the firmware --- anyone recall PlaidNet --- that was another sensationalist thread from green that I will have to dig up
It lived IN PRODUCTION for 2 or 3 months and then "poof" disappeared.

This finally brings me to the last point
3 - a DEV build - no matter how you look at is - does not equal a PRODUCTION build (!==) you still need to run a set of tests with the hardware under test (like a radar) against a production build.
And we do not know how extensively they were testing this and for what purpose.

You seem to take greens speculation on faith -- because he saw X in the firmware!

 

[Knightshade]

1 - real testing happens with real hardware! which requires real firmware

In what way, specifically, is developer firmware not "real"?

it runs with real hardware, on real cars.

The only difference is it doesn't get pushed to the consumer fleet, but only specific cars for development testing.

2 - false, what I called green delusional for is that seeing something in firmware somehow guarantees release to end user

Which he never said.

He said it appeared Teslas own radar development wasn't working out (which turns out is accurate since no such product ever showed up)

He then said so they apparently decided to buy a radar from another company.

Which is also factually true because how else would it be in the firmware, and how else would they have been testing the hardware as you just claimed was the reason it was in the firmware in the first place?



He did not "guarantee" it would move to mass production as you claim. At all.

That's you grasping at straws to find something to call him 'delusional' about.

-- my exact quote: "And he seems to be delusional enough to think that because he saw it in the firmware he somehow predicts its arrival in the actual fleet"

In the majority of cases, what he's seen in firmware did arrive in the actual fleet.

It's not a 100% guarantee of course. Sometimes Tesla goes down a path and finds it's a dead end and doesn't deploy it.

But it's true far more often than it's not.

Which is kinda the opposite of "delusional"

3 - a DEV build - no matter how you look at is - does not equal a PRODUCTION build (!==) you still need to run a set of tests with the hardware under test (like a radar) against a production build.

You don't seem to understand the words you're using.

The final version of a development build can be literally identical to a first production build (and often is!) apart from:

The literal version number
and
The audience it is released to.


Elon frequently mentions his PRODUCTION Tesla is driving around on a DEV BUILD of the firmware for example.

There is nothing whatsoever magic about a development build that prevents you from fully testing something in exactly the same way a production build would test that thing.

In fact- that's often the point

You want to be done testing before it goes to production ideally.

 

[mikes_fsd]

There is nothing whatsoever magic about a development build that prevents you from fully testing something in exactly the same way a production build would test that thing.

You are right magic has nothing to do with it.

In the real world - a development build, at the very least, is more verbose - it can have additional logging/debug that automatically gets stripped when you build a production release.

Could a development build be exactly the same as a production build - in theory yes, but in practice, I've never had that happen.
You will want your production build optimized and unnecessary logging/debugging turned off / removed.

If you cannot guarantee that the development build is identical to the production build, you must run the build through your test suite before you deploy it anywhere.

This is nothing new, has been a standard practice in for a while.

 

[Knightshade]

You are right magic has nothing to do with it.

In the real world - a development build, at the very least, is more verbose

False.


One of the projects I update fairly often, the dev code is identical to the production code other than whatever specific thing we are testing that only exists in the dev code

This avoids any concerns about bugs creeping in from another other than what we are testing.

- it can have additional logging/debug that automatically gets stripped when you build a production release.

It can.

It doesn't have to.

And if it did or not would hurt your arugment since you claimed it needed to be in the production code to be tested properly- yet here you say the dev code is better for testing.


So you still haven't offered any remotely non-delusional reason it'd show up in the production code if there was never an intent to put it in production

Could a development build be exactly the same as a production build - in theory yes, but in practice, I've never had that happen.

Not sure why you think your limited experience should apply to everything though?

As I mention I've seen exactly that happen.

If you cannot guarantee that the development build is identical to the production build, you must run the build through your test suite before you deploy it anywhere.

Which is a really good reason why some projects do use identical dev and prod builds apart from the one thing that's changing.

When my testing on the one project I mention is done against the dev build for example I literally copy and paste the code into the same place in the production build since nothing else is changing.

You will want your production build optimized and unnecessary logging/debugging turned off / removed.

Sure.

But you wouldn't put something in it you don't actually plan to ever put in production right?

That's the OPPOSITE of why you roll code to production, right?

Hence, the fact the new radar showed up in the production code suggests they intended to use it in production

Then it seems later changed their mind. With at least 3 possible reasons why already suggested earlier in the thread.

 

[mikes_fsd]

But you wouldn't put something in it you don't actually plan to ever put in production right?

That's the OPPOSITE of why you roll code to production, right?

Hence, the fact the new radar showed up in the production code suggests they intended to use it in production

You must live in a fairly land where things are done one independent thing at a time.

We've introduced isolated (internally tested) code into production to gather performance statistics, that would affect only a small portion of a large application.
Like a different dependency. It is in production, we gather our data and then it is removed from production in the next release.

Just because you do not understand something that is more complex than your trivial example doesn't automatically make the more complex examples wrong.

Neither you nor green know what they were testing on the production firmware for that radar unit.
You and green want to make assumptions and pretend that your assumptions are correct.

Sorry to burst your bubble, but on several occasions (4D radar and PlaidNet are just two examples in this thread) greens assumptions have been proven flat wrong.

 

[Knightshade]

You must live in a fairly land where things are done one independent thing at a time.

Weird how every time a real life example proves you wrong you call someone names or mock the real life facts on the ground.

We've introduced isolated (internally tested) code into production to gather performance statistics, that would affect only a small portion of a large application.
Like a different dependency. It is in production, we gather our data and then it is removed from production in the next release.

Again your reply is delusional.

How can code to run a radar system not physically in the vehicle gather performance data?

And why couldn't a DEV build in a car gather that data? Because again DEV builds are tested in real cars all the time- meaning there'd be no reason to roll the new radar code to PRODUCTION unless you intended to USE IT IN PRODUCTION.


I've asked that last question multiple times and you keep having no answer that even resembles a coherent explanation.


I'd advise you to quit while you're behind, but you seem to enjoy digging so keep making this whole deeper, it's hilarious.

 

[mikes_fsd]

How can code to run a radar system not physically in the vehicle gather performance data?

You keep making up assumptions. Stop it.
I was giving an example of what we've done in the past. I do not know what Tesla needed to test and why they deployed the firmware build the way they did, NIETHER do you or green! That is the whole point!

Clearly they had a test case, they tested it and moved on with their lives.

Enjoy your fantasies!