-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
FSD v12.x (end to end AI)
- Thread starter Buckminster
- Start date
-
- Tags
- #fixphantombraking autopilot chill is not chill elon is an ass fix fsd extreme late deceleration fsd does not commit to go fsd does not maintain proper speed fsd hard and late braking fsd has decision wobble fsd jerky driving fsd late deceleration fsd sometimes may not detect train crossings fsd stops too early too quickly fsd stops too far behind line fsd tailgating in city streets
sleepydoc
Well-Known Member
Not really, but I’ve seen/experienced the explanations you suggested and can say that they don’t apply to the majority of situations in which FSD inexplicably aborts a lane change.
Um. "Emulation". You guys are using that word in ways that it probably doesn't mean to be used.
Say that one has two CPUs, an old one and a newer one of the same general type. The newer one can do everything the old one can do, possibly with an additional step or two in the microcode, but the newer one would have additional capabilities.
With the right compiler flags set, the same code base, designed for the older CPU, can be run on the newer CPU sans problem or, depending upon just how the low-level instructions are set up, with no degradation is speed.
It gets to be even more fun: Say that the newer CPU is actually faster on individual instructions or something. But also state that the code base has a timer set that interrupts whatever CPU we're talking about and has it dump the results of some calculations; then we start up again with more calculations and another dump. The time it takes to do the calculations may be faster on the newer CPU - but, if one stops and waits for the timer to trigger the interrupt before continuing, there will be no difference in speed from an outside view between the newer and older CPU.
With this kind of setup, an engineer will say that the newer CPU is "emulating" the older CPU: Same top level code, possibly slightly different assembly/microcode, but the same results.
Now, there's another use of the word, "emulation" that one runs into from time to time. Say that one has a x86 CPU. It's perfectly possible to have, with the right compiler, to take source code for, I dunno, a Motorola 68000 CPU and generate 68000 assembly language, all on that x86 CPU. (Read: Cross-compilers.)
One can then take that 68000 assembly language and feed it into an emulator that steps, one 68000 instruction at a time, through the code. The emulator is a program that, somewhere down in the basement level, is actually executing x86 assembly language. Fun. With the right kind of GUI, one can watch 68000 CPU registers being loaded with values, memory space being modified, and code being executed right along, great for debugging.
But run the Sieve of Eratosthenes on the code loaded into this 68000 emulator and it will be much, much, much slower than running it on native 68000 hardware.
Usually, but not always, when people are talking about the "new" vs. "older" CPU above, the word, "compatibility" mode will sometimes get bandied about. But the term, "compatibility mode" is usually reserved for flipping an actual hardware bit that changes the operation of the underlying hardware in some way.
So: Given Elon's usage of the term, "emulation", I think he's talking about a more capable CPU that (most likely) isn't using an expanded instruction set or (somewhat less likely) has some small libraries of assembly that convert older instructions into newer ones.
And, in either case, isn't some massively slowed down emulation system running on some completely different hardware.
Say that one has two CPUs, an old one and a newer one of the same general type. The newer one can do everything the old one can do, possibly with an additional step or two in the microcode, but the newer one would have additional capabilities.
With the right compiler flags set, the same code base, designed for the older CPU, can be run on the newer CPU sans problem or, depending upon just how the low-level instructions are set up, with no degradation is speed.
It gets to be even more fun: Say that the newer CPU is actually faster on individual instructions or something. But also state that the code base has a timer set that interrupts whatever CPU we're talking about and has it dump the results of some calculations; then we start up again with more calculations and another dump. The time it takes to do the calculations may be faster on the newer CPU - but, if one stops and waits for the timer to trigger the interrupt before continuing, there will be no difference in speed from an outside view between the newer and older CPU.
With this kind of setup, an engineer will say that the newer CPU is "emulating" the older CPU: Same top level code, possibly slightly different assembly/microcode, but the same results.
Now, there's another use of the word, "emulation" that one runs into from time to time. Say that one has a x86 CPU. It's perfectly possible to have, with the right compiler, to take source code for, I dunno, a Motorola 68000 CPU and generate 68000 assembly language, all on that x86 CPU. (Read: Cross-compilers.)
One can then take that 68000 assembly language and feed it into an emulator that steps, one 68000 instruction at a time, through the code. The emulator is a program that, somewhere down in the basement level, is actually executing x86 assembly language. Fun. With the right kind of GUI, one can watch 68000 CPU registers being loaded with values, memory space being modified, and code being executed right along, great for debugging.
But run the Sieve of Eratosthenes on the code loaded into this 68000 emulator and it will be much, much, much slower than running it on native 68000 hardware.
Usually, but not always, when people are talking about the "new" vs. "older" CPU above, the word, "compatibility" mode will sometimes get bandied about. But the term, "compatibility mode" is usually reserved for flipping an actual hardware bit that changes the operation of the underlying hardware in some way.
So: Given Elon's usage of the term, "emulation", I think he's talking about a more capable CPU that (most likely) isn't using an expanded instruction set or (somewhat less likely) has some small libraries of assembly that convert older instructions into newer ones.
And, in either case, isn't some massively slowed down emulation system running on some completely different hardware.
we have to remember that its Boris, so he only ever had a tenuous connection with facts anyway
U-Turns in general aren’t reliable for me. It’s too slow, doesn’t turn right enough (humans just go full lock), and sometimes bails out.
Definitely an area of disappointment for me with V12 even though it technically can complete them sometimes.
Just to clarify there is no U-turn on this road. It's simply a 2 lane secondary road. FSD just stops in the lane I'm in and sits there forever. I've been told 5 years ago the road was closed for bridge construction but the road has been open for years. If you drive the road from the other direction it's fine. Here is a screen shot including the navigation map.. The correct route is simply making a left turn at the Stop sign. Should just be a very simple left turn. I've reported to Tesla many times. I wonder what Robotaxi will do?
I started to type a dumbass version of this and stopped. So thanks for sparing everyone my babbling mostly incoherent word salad drawl.
I see. I suspect this is a combination of multiple failures here:
1. The navigation is supplying bad guidance. Maybe it thinks that intersection is a no left turn (there’s one near me like that)
2. FSD (the AI driving part) more or less tries to follow the nav, and it’s not all that intelligent. In this case it’ll happily make the unnecessary right turn. Then once it reaches the U-Turn it probably just gets stuck because U turns aren’t well supported.
In addition to U turns not working well, eventually I suspect the navigation system is going to need more bidirectional integration with the driving AI to figure out how to handle cases where the nav data is off. Road closures for construction are a good example.
Regarding the video quality, I think it's more likely that HW4 video output downrezzed (aka down-sampled aka decimated) to HW3 will be of somewhat higher quality. I haven't seen any direct comparisons but:
- There are theoretical and practical benefits from the original image being taken at a higher resolution i.e. spatial sampling frequency. I wouldn't put too much on that without testing and knowing more about the level of anti-aliasing measures taken in both hardware setups.
- Aside from pixel resolution, I believe the new cameras can operate at a higher frame rate. I don't know if they are simply being run at the HW3 rate now, or if the video is being processed to normalize the rate.
- Perhaps the larger effect, in the Tesla HW3-HW4 case, is that the newer-generation cameras supposedly do a better job of suppressing sensor overload artifacts from bright sun in the frame. It's also likely that the low-light performance and noise floor is superior.
I agree that the video down-sampling is not the whole story regarding Elon's comment. Aside from the question of video input quality, I think he means that clips from both HW3 and HW4 are used to train the same model, and then both in-car computers are running the same inference model. Not taking any real advantage of the more powerful computer in the HW4 vehicles.
While in general, there can be a loss of performance in having one computer type run another's native code using an emulation layer, I don't think that itself is a significant problem here. I would be shocked if the HW4 computer had not been engineered to run HW3 code directly at full performance; I think it was essentially a mandatory design requirement for the rollout of functional HW4 vehicles in 2023. Perhaps "compatibility mode" would have been a clearer term.
So I don't think the "emulation" represents a loss of quality in video or in compute - more likely some modest actual gain in the former. Elon's comment should mostly be taken to mean that HW4 hasn't achieved its full potential, because they haven't yet deployed a version customized for it.
zoomer0056
Active Member
Maybe so, but so far this is the best guess I've read as an explanation for emulation.
I think HW3 emulation is only related to the video input part. Maybe they convert the HW4 video image to have the HW3 resolution? It's like playing a 4K movie on a 1080p TV?
I don't think it's similar to run VMware on a PC.
I don't think it's similar to run VMware on a PC.
Took a trip w my 24 mylr from my home in the east bay to Santa Cruz for my wife's bday.
Fsd 12.3.6 performed great on hwy 17. For those that don't know, hwy 17 is a very whindy 2 lane (each way) hwy where lots of accidents happen because of how whindy it is. Zero interventions.
I found it interesting that fsd 12.3.6 used the city stack instead of the hwy stack on hwy 17 as it had the auto speed setting enabled w no ability to adjust the max speed like u can using the hwy stack.
Fsd made the trip relaxing instead of stressful.
Fsd 12.3.6 performed great on hwy 17. For those that don't know, hwy 17 is a very whindy 2 lane (each way) hwy where lots of accidents happen because of how whindy it is. Zero interventions.
I found it interesting that fsd 12.3.6 used the city stack instead of the hwy stack on hwy 17 as it had the auto speed setting enabled w no ability to adjust the max speed like u can using the hwy stack.
Fsd made the trip relaxing instead of stressful.
Last edited:
Didn't someone say the driver camera had infrared or something, that could track your eyes at night?
I drive mostly in the daytime, since my low light vision is not what it used to be. With absolutely no pressure on the steering wheel, I've had virtually no nags while driving daytime since 12.3.6.
Last night I drove home at night and I got nags like every minute, until I started keeping steady pressure on the wheel. Is my infrared broken?
I drive mostly in the daytime, since my low light vision is not what it used to be. With absolutely no pressure on the steering wheel, I've had virtually no nags while driving daytime since 12.3.6.
Last night I drove home at night and I got nags like every minute, until I started keeping steady pressure on the wheel. Is my infrared broken?
FSDtester#1
"Circle Jerk Old Guard" per cyborgLIS aka "CJOG"
Take your cellphone out to your car, turn on your camera and look to the left and right of the cabin camera. There are 2 infrared lights in some cars you can only see with a phone. You don't need to take a picture or video.
Newer models (different years for some) have IR transmitters that beam IR toward your eyes. Unfortunately they are not in the most ideal placement nor are the cameras the way they are in dedicated eye tracking systems like GM or Ford.
FSDtester#1
"Circle Jerk Old Guard" per cyborgLIS aka "CJOG"
Last edited:
Yes but it is an ad hock system using a normal angle vision camera NOT directly looking at the driver (looking at the cabin). IR dedicated tracking systems use IR transmitters usually straight at the driver behind the steering wheel and a camera with a narrow angle of view and likely tuned manly for IR facing straight at the driver's face area only.
Edit: Here is Ford's with the IR on the sides and the camera in the middle.
zoomer0056
Active Member
I've riden Hwy 17 from Scott's Valley to Los Gatos every day on a motorcycle for work in the 90s. Very fun on a bike. I can imagine how FSDS makes it a piece-o-cake. My commute was just exciting.
Last edited:
FSDtester#1
"Circle Jerk Old Guard" per cyborgLIS aka "CJOG"
It still works however, been busted a few times with the red warning
. Why does it have to yell at me every time I get in the backseat to get some shut eye?
