robbies
robbies on Hacker News
Words do mean something, and you could have taken 5 minutes of research to make a reasonable counterclaim
Tesla has an insane PE ratio because it’s a casino stock (~350x). As a comparison, NVIDIA IS 40x. SpaceX
Is projected to be 300-500x. These are fantasy, completely unrealizable valuations. Similar to Enron, and Enron was over 70x. Enron wasn’t some surprise either.
Typically when PE gets out of whack, market analyzers dig into what is happening because it’s usually chicanery. No longer. Everyone is along for the ride.
On point #2, they are trying to do that right now. If spacex is fast tracked into the indices, passive investors via index funds will be forced into buying.
100% this, it's fucking insane
Somehow he's flipping $1T SpaceX + $250B xAI (which is now apparently a pile of trash, according to Elon) into a $1.75T IPO because all of the insider investors think they can get away with it, and they are probably right
> And that the result will be Iran becoming a democracy that fully joins the global community.
You can hope that (and I can hope that), but the powers that are driving this military action completely do not care about this outcome. Which makes it exceedingly difficult for me to think this will happen.
I know the US proxies keep blabbering about 'regime change', but there's zero intentionality behind the political work to do that. My guess is balkanization, which won't really go how the US/Israel wants it to go
What do you like to use instead? I’ve used the aider leaderboard a couple times, but it didn’t really stick with me
I know enough people at Apple who are at the mercy of the overlord design teams, and it sounds exactly like what you described
I’m being earnest: what is an appropriate level of computer architecture knowledge? SIMD is 50 years old.
From the resource intro:
> Expected background: We’re going to assume you have a basic understanding of LLMs and the Transformer architecture but not necessarily how they operate at scale.
I suppose this doesn’t require any knowledge about how computers work, but core CPU functionality seems…reasonable?
As a real time rendering engineer, this is how it’s always been. NV obfuscates much of the info to prevent competitors from understanding changes between generations. Other vendors aren’t great at this either.
In games, you can get NDA disclosures about architectural details that are closer to those docs. But I’ve never really seen any vendor (besides Intel) disclose this stuff publicly
They “learned” this trick from their consumer days. Devs always had to reverse-engineer the hypothetical scaling from their fantasy numbers
I appreciate this perspective, good points, thanks
(New to comment thread)
The article is about setting up all the core infrastructure to start bringing content into the engine, validated by the triangle.
Even tho the Vulkan tutorial might seem like work, it’s not actually preparing you to build anything significant on top of it. This just an overview of the API, not much of a building block.
Oh great, you’re piling onto the obtuse pile
Don’t you think this is already happening for most AAA production tech? Most high performance real-time stuff does go top-down. Mid-core stuff or art tooling might be fine with bgfx (or this I guess).
That's an interesting idea. I wouldn't really call the Raster Block a 'queue' in most GPUs. The most queue like thing is the buffer used to store non-position exports from VS, but then those are interpolated before dropped off into PS. There's a lot of fixed function machinery to convert vertices into fragments (setup, cull, clip, rasterize, early Z/S).
And that's not even considering the vast differences between AMD and NV here. And then there are the mobile GPU constraints.
Still, would be fun to export more of the controls here. If you have access to a console devkit, some of these knobs are exposed.
Oh interesting. TBH, I have zero knowledge on how to do any of this on the web side. All my experience is from working with traditional game engines on the native side.
But now the industry is moving away from pure deferred, as it scales poorly with higher resolutions. 4K, high res mobile devices, VR...
Modern game engines parcel out work via a job system, where functional tasks are dispatched to the cores in a system. This is opposed to the idea of 'one core/thread will own a task for the lifetime of the application, while checking in with a master core/thread'. Actually, most games have a hybrid model. Usually one thread/core is dedicated to rendering, another thread/core is dedicated to high priority tasks/jobs, and then the remaining resources are used by whatever jobs are left.
http://fabiensanglard.net/doom3_bfg/threading.php
UE4 is not the most widely used game engine in the industry. That would be Unity by a wide margin.
If you are restricting to AAA, I’m not even sure if that holds. There are a good amount of big teams that use UE4, I think I’d go with Frostbite due to the sheer amount of titles that EA pushes out that are now based on Frostbite. It’s certainly more big games than UE4 is shipping. I’d probably put Ubisoft ahead of them too with their internal engines.
If there's more work to do than what the current employee set can do in 40 hrs/wk, then the team didn't hire enough employees. I realize that rare is the team that is fully staffed, but the employee shouldn't be obliged to make up the delta because management didn't hire appropriately.
As a lifelong Bay Area resident, I honestly never thought I'd see this day. I've had a lot of fun teasing my friends in the public sector about their BART/CalTrain extension optimism, but maybe those days are coming to an end...
I would actually argue that it is _bad_ for graphics. The GPU abstraction that OpenGL represents is now 30+ years old, and not at all representative of how modern GPUs (desktop or mobile) work. I'd even argue that OGL obfuscate the GPU machinery to all the budding graphics programmers who use OGL. OGL was never meant to be a graphics toolkit/middleware, but that's what it's become (at least the compat profile).
As far as the value to you, to be perfectly frank, you would not have compatibility profile if it wasn't for workstation ISVs demanding OpenGL 1.1 still be supported for their legacy applications (and shelling out the big bucks to maintain that support). There isn't a singly IHV who is keeping these legacy features on for any hobbyist or learning programmer. Not one. The IHVs know it's bad, but there's a lot of money in keeping it around.
I don't even know if there's value in mentioning this, but I used to be an OpenGL driver engineer, and then when I worked on it, I realized "Hey, wtf, this has nothing to do with how the GPU works!" I'm still happy/proud about the work I did, but I don't think it advanced the graphics state-of-the-art (for the most part, there are some cool things that showed up first in OpenGL). And then as far as the cruft I mentioned...it's just a psychotic maintenance nightmare.
Sure, ATI/AMD (and Windows Intel) lagged behind NV in the full OpenGL implementation. But the "compatability" profile is full of a lot of cruft that had nothing to do with modern GPUs, and whose primary value was to passing workstation test suites, not actual modern GPU programming.
I know we have the "but mah immediate mode" crowd, but those folks have to just get off it. Write your own immediate mode recorder if you're so desperate. I'm also looking at you, matrix stack abusers. Your programs are bad, and you should feel bad.
Even if the users acknowledge it is bad to keep using NVIDIA (and allow them to continue domination), what are they supposed to do?
From my view, it's not just that CUDA > OpenCL. Rather, it's CUDA ecosystem >>> OpenCL ecosystem. The tools, the libraries, the documentation, the community - all of these are superior on the CUDA side. If you give all those up to use OpenCL, how do you make up for that cost?
"I wonder if that's intentional on NVIDIA's part."
I think that's a reasonable guess. NVIDIA only supports OpenCL 1.2 (and it took them about 6 years to get there from 1.0, while other vendors were at 2.x).
While I don't think NVIDIA ever outright stated OpenCL was on the back burner, their support clearly waned, which devs noticed (https://streamcomputing.eu/blog/2012-09-10/nvidias-industry-...).
As for why...well, why should NVIDIA participate? They don't have anything to gain when they already have CUDA dominating the industry.
I don't think this is too surprising for any person of color. For myself, I've learned that I have to plan 'extra ahead' in order to make sure I have time to correspond with multiple hosts, in order to work around the calendar being wrong or other 'reasons'. I've been cancelled too many times with Instant Book for 'reasons'.
Beware all who are reading below this comment: it's aggressively misinformed. It starts with this comment, which is almost completely inaccurate. And then it continues from there. Wth HN...
Releasing source for graphics drivers has zero to do with this DirectX Shader Compiler going open source. This compiler just compiles from HLSL to DXIL. During run-time, the application submits DXIL to the IHV driver for compilation into machine bytecode. And that compiler is still closed-source, at least for most GPU use cases.
I don't understand what you thought you'd accomplish with your comment. It's almost a willful attempt at not understanding what the project/event is about.
> ...a lot of Chinese cuisine has ways to cook these into something tasty.
Not exactly. They just like chicken feet. Cultural palate. You can go to a dim sum place (if you have one available in your US town) and get dim sum. If you don't like them already, pretty good chance you won't like them off the cart.