ireallywantthat

Will it work without Tesla.com account? Or no internet access at all? I just want to drive the Tesla car without internet without any smart features. Is that possible?

Another SAAS embedded within Car which cannot be opted out. Is there a way to get FOSS Tesla? IMO the Government must intervene to make this opt-in rather than compulsory?

If you are that knowledgeable person in this domain, try to refute/discuss my content instead of asking my credentials.

What is the best alternative to Vulkan extensions in your opinion? Remember that Vulkan supports vast number of devices. I think that making featureset mandatory for all devices is not sensible approach here.

> Why didn't Microsoft immediately embrace it? Or Sony? Or...

Because they are already established platforms in Gaming Industry? Windows has much of Gaming market share. Xbox and PlayStation are popular Consoles. They probably don't loose anything by supporting Vulkan although supporting Vulkan would be awesome on their part.

> Ah yes. They are losing because of not supporting Vulkan.Xbox is DirectX. Playstation is GNM and GNMX

I was only talking about MacOS.

> before you say that more people are gaming on Android, iOS's mobile gaming revenue dwarfs Android

I didn't talk about iPhone either. I was only talking about MacOS. despite being prominent OS, game title developers often ignore MacOS. Why? Because of Graphics API. No one bothers to target Metal for Games and this is exactly what i am talking about. If MacOS allows Vulkan or DX(ik that it's not possible), i think there could be more influx of games.

If we are talking about Gaming on iPhone, you must know that gaming landscape on mobile phones is vastly different than that of mainstream gaming experience on Consoles/PC. Mobile gaming landscape is mostly filled with non graphics intensive, micro transactions filled, Ad-filled(many times freewares) games. iPhone gets targeted because it has prominent share in Mobile Market but even then, not everything gets ported to it. Not to mention, Android gaming landscape doesn't suck than iphone. Prominent Mobile games which are on iPhone are on Android too and on Android they use Vulkan which proves that Vulkan is not a bad choice.

> Xbox is DirectX. Playstation is GNM and GNMX

Vulkan probably runs on PlayStation (see latest Baldur's Gate 3 patch notes; grep for PS5 Vulkan) but I am not so sure. Like i said earlier, these platforms are already household names when it comes to gaming.

My point was not to tell you that Vulkan is the "supreme" Graphics APIs out there. But my point was to tell you that Vulkan is the only one of "supreme" APIs which is most cross platform, modern, supported by gaming and graphics forerunners(valve, rockstar, nintendo) and there are no viable alternative to Vulkan right now.

> Yes, we can and should blame Khronos. For their mismanagement of OpenGL

What should they have done? At the point, we needed modern Graphics API. Mantle by AMD was forerunner and AMD was willing to co-operate. Nvidia too joined that bandwagon. Thus, Vulkan was born out of Mantle.

Should they have copied Metal? Since it was closed API from Apple, it wasn't possible. Should they have copied Microsoft's DX12? If Microsoft actually loved Open Source and Standards and gifted Khronos DX12, it would have been possible but they didn't do it. I think Khronos did sensible thing at that time.

I agree that Microsoft has no part in this. But, any computers which run Microsoft Windows has GPUs made by these Manufacturers: Nvidia,AMD,Intel and Qualcomm and all these Manufacturers have good Vulkan Drivers in Windows.

Thus said, even though Microsoft doesn't support Vulkan officially, you can tell that Vulkan has first class support on Microsoft Windows given that all GPU drivers have good first class Vulkan support and all Vulkan Applications run just fine on Windows.

> In reality, Vulkan doesn't matter much except on Android and Linux.

No, it matters. Vulkan is the first modern cross platform Graphics API which can run across Linux,Windows,Android,MacOS,Switch to name a few. No similar API does exist currently which offers high performance along with being portable.

You know that Vulkan targets vast amount of Hardwares which makes Vulkan Extensions a lucrative deal rather than thing you despise, right?

Don't get me wrong. I agree that it's less worrying to know beforehand that all the features will be available in the target environment with features made mandatory rather than extensions. But, it's not like the case of Apple/Sony/Xbox which has software tailored for the device.

Vulkan devices range from Virtual devices(Moltenvk) to Android(Low powered devices) to Desktops(Linux, Windows) to Workstations(Linux). Having ray tracing mandatory in low powered devices like low budget android phones doesn't make any sense, that's why it's made as extension.

But, you can be sure that any modern desktop with modern GPU by any vendor atleast adheres to Vulkan standard and has specified extensions available. That can't be said about experimental extensions though (Like Vulkan Video).

> Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.

This "multiple backend" solution is not ideal too. Firstly, it was necessary because not all Vendors supported single Graphics API standard. Secondly, it isn't powerful as main API it gets translated to(DX,Vk,Mt). Thirdly, I don't see how it helps when target environment doesn't have an extension available.

Maybe "Multiple Backend" solutions might make few things easier like removing Verbosity and maybe they are good for Small applications but I don't think they are worthy replacements to Main APIs

> Why would Apple support something that appeared two years later than Metal?

Because Vulkan is Open Standard? It's similar to how EV car manufacturers other than Tesla are now embracing NACS even though it was born at Tesla. It's also similar to how Apple adopted USB C given Lightning was already a standard before USB C.

You can't blame community or Khoronos either. Khoronos and developers did their best with best effort Vulkan-> Metal translator with Moltenvk and you can now not worry that your Vulkan apps won't run on MacOS(exceptions are heavy games and there are still many Vulkan extensions not implemented thanks to Metal).

And note that it's not you or I who is losing because Apple didn't support Vulkan. It's Apple themselves whose Mac devices have started losing share in Gaming Market. Day by day, Developers are ignoring MacOS as target. If this isn't a warning call to Apple, i don't know what is.

You know that Games/Applications can still be developed with Vulkan API targetting win32 and they can be run on Proton/wine in Linux which runs it without the DXVK (dx11->vk)/VKD3D (dx12->vk) translation layer, right? Baldur's Gate 3, Red Dead Redemption 2 are some of popular games which use Vulkan exclusively running on Proton.

This way you can evade proprietary DirectX12.

> it _has_ to use the system-provided Java APIs.

My original comment was against this. Why should this be the case?

> Skia is not something you use to write apps: it's a graphics engine, essentially something you use to draw polygons on the screen.

So, AOSP team can obviously create Rust framework ontop of Skia(or tinyskia,femtovg,etc.), make Android APIs available in Rust, Create proper widget framework and let us create Android Applications written entirely in Rust.

> Linux desktop is certainly not the dream world you describe. Practically, you _have_ to pick a toolkit: one of GTK / KDE / Qt / electron / etc. Maybe it helps to think of Android's toolkit (Views or Compose) as one of those.

I know what I am talking about. This is exactly the freedom that I was talking about. I am able to choose any framework/toolkit I want. If i don't want any framework, that's fine too. You don't have that freedom in Android. Everything has to be routed via Java ecosystem that AOSP constructed.

Calmed down.

> behind JNI walls, and even NDK code is obliged to make use of JNI to call into them.

What i originally told was "enable us to let create Android Applications entirely in Rust (including the GUI)" . Surely Google and AOSP projects can remove the restrictions that you mentioned and provide us alternative to Kotlin/Java ecosystem which is what i really want and hope them to do. Smartphones powered by Android are capable computers and freedom for App development is appreciated.

Please don't mention once again that "X is not implemented in AOSP. Y is required to make use of JNI calls into them". You know that this is superficial barrier and can be overcome/corrected if they wanted to.

Ok, now enable us to let create Android Applications entirely in Rust (including the GUI). Let's get rid of Kotlin/Java monopoly in Android App development. Shall we?