Often not elusive bugs, but elusive performance. GPU compilers are hard: Once you've done the basics, trying to do further transforms in a mature compiler will almost always produced mixed results. Some kernels will go faster, some will go slower, and you're hoping to move the balance and not hit any critical kernel too hard in your efforts to make another go faster.
An optimization with a universal >=0 speedup across your entire suite of tests is a really hard thing to come by. Something is always going to have a negative speedup.
My experience is with non-Nvidia GPU systems, but this feels like a familiar situation. They probably found something that has great outcomes for one set of kernels, terrible outcomes for another, and no known reliable heuristic or modeling they could use to automatically choose.
IMO the problem is that H1B employees are stuck at the employer for the duration of their green card process, and so end up both paid lower and unable to escape abuse.
I think a very high application fee is actually part of a good solution, but is useless by itself.
A flawed proposal:
* Dispense with the 'need to search for a qualified American' which just complicates the process without achieving the stated goal, and includes a ton of legal and bureaucratic expense and time.
* A large application fee paid from the company to the federal government.
* The worker's relocation expenses must also be covered by the company.
* The worker gets a 10 year work authorization on the day of their arrival.
* The worker gets to leave their sponsoring employer on the day of their arrival, if they choose to. The employment contract may not include any clawbacks of anything.
The latter bullet is the key one. That's the one that uses market forces to truly enforces this person is being paid above market wages, and is being treated well, at their sponsoring employer. (which in turn means they don't undercut existing labor in the market).
It also means that employers don't really look abroad unless there really is a shortage of existing labor. But when there is a true shortage and you're willing to spend, the door is open to act quickly.
The obvious defect is that it creates an incentive for the employee to pay the federal fee themselves (hidden) plus more for the privilege of getting sponsored, and the company basically being a front for this process. Effectively buying a work authorization for themselves. I'm not sure how to overcome that. Then again, the current system could also suffer that defect (I don't know how common it is).
DOTS/ECS has nothing to do with geometry LODs. Those are purely optimizing CPU systems.
Even if DOTS was perfect, the GPU would still be entirely geometry throughput bottlenecked.
Yes, UE5 has a large competitive advantage today for high-geometry content. But that wasn’t something Unity claimed could be automatically solved (so Unity is in the same position as every other engine in existence apart from UE5).
The developer should have been aware from the beginning of the need for geometry LOD: it is a city building game! The entire point is to position the camera far away from a massive number of objects!
Despite the original post talking about DOTS rough edges, I didn't see anything in that article that actually suggested DOTS was the cause: that would cause CPU overhead, but it seems like they simply have a bunch of massively over-detailed geometry, and never implemented any LOD system.
Maybe they could have gotten away with this with UE5's Nanite, but that much excessive geometry would have brought everything else to its knees.
An optimization with a universal >=0 speedup across your entire suite of tests is a really hard thing to come by. Something is always going to have a negative speedup.
My experience is with non-Nvidia GPU systems, but this feels like a familiar situation. They probably found something that has great outcomes for one set of kernels, terrible outcomes for another, and no known reliable heuristic or modeling they could use to automatically choose.