Hacker Newsnew | past | comments | ask | show | jobs | submit | MayeulC's commentslogin

I think it should be fine with async reprojection.

Honestly, it wouldn't surprise me if this was a conspiracy to crash the "west" AI labs. Might as well pop the AI bubble and see the USA economy go down the drain. Even if not orchestrated, I am sure they see how they could benefit from that outcome.

Now, all this talk of pacing the frontier obviously means that they are afraid of the competition. It could be the open models eating their margins, but also competing frontier models forcing them to invest more and more for diminishing returns, just to keep up. They would certainly benefit from a "Moore's Law" roadmap to pace the advances, and seeing that they lobby for US laws, it would probably mean they are more worried about increasing spending. Though outlawing both open models and Chinese models would be good for their bottom line as well.


I think that "machine translator" is a much better metaphor: there is a lot more to translating a text than there is to compiling code: contextual cues, cultural settings. Various translations can be equally valid. All translations are imperfect.

Now, if you excuse my ramblings, here are a few ideas: I think we probably need new "programming" languages that are actually specification languages: reproducible default states, deterministic spec-to-code transformation.

I am not sure we actually need the determinism, but that would be a good property to have. At least with the same model/spec/temperature.

Now, prompts mutate the spec, which can also be edited by hand. You can already do this with the final code of course, but it is tedious as it contains many trivial implementation details.

But then, how do you handle bugfixes that need to persist during re-generation? Such as "Both Foo and foo can be present in the same directory if the file system is case-sensitive". If you add them to the spec, you are micro-managing implementation details again. So I think such "bug fixes" should be part of a prompt/spec that is automatically loaded when generating similar snippets (here, file I/O). It feels like I've just reinvented the concept of software libraries, though.


The four-vector contains coordinates of a point in time and space (x,y,z,t).

As a sibling said, light travels forward in time, but also from a light source towards the camera. Raytracing traces rays backwards from the camera (because there are fewer rays to trace this way: just pick the ones that land on the camera and work backwards towards light sources). So backwards in time, trying to figure where the ray originally came from.

Anyway, you need to keep track of the time dimension as light moves (at constant speed) through spacetime in a straight line, but the black hole also stretches the time dimension, affecting what a straight line looks like for an outside observer.

That's my understanding at least, I am not that well versed in relativity.

Edit to make it more interesting: (x, y, z, t) is your position in spacetime, I do not quite understand how you can take its derivative¹ (probably not time-wise), but you can derive the four-velocity, the magnitude of which is constant (c). Intuitively (and probably naïvely) I understand this as: you move trough spacetime at constant speed. Therefore, if your spatial coordinates move faster, your time coordinate moves slower. This gives you back the special relativity results with time that "slows down" for fast-moving objects.

https://en.wikipedia.org/wiki/Four-vector

https://en.wikipedia.org/wiki/Four-velocity

¹: derivated along the "proper time" (time from the perspective of the moving object) according to Wikipedia. Still unsure how to compute that.


In a Lorentzian manifold like the spacetime of special relativity (which we'll focus on here) nonzero tangent vectors at spacetime point p (i.e., for any curve passing through p) can be in three separate categories: spacelike, null, and timelike. Details <https://en.wikipedia.org/wiki/Causal_structure>. Curves that physical objects travel are typically timelike at every point (for objects with inertial mass) or everywhere null (for objects with no inertial mass). When unaccelerated, i.e. in inertial motion, rest mass determines whether the object is on a timelike geodesic or a null geodesic.

Four-velocity is defined on a timelike geodesic - its four functions take proper time as a parameter.

Proper time is a parametrization of a timelike geodesic which has several useful properties: it is monotonic allowing for orientability, and gives a unique real value for every infinitesimal point on the geodesic. This in turn means the tangent vector is preserved when parallel-transported along the proper-time-labelled timelike geodesic, with the gross physical meaning that the direction and speed of travel (in local forward/left/up coordinates for example [1]) does not change as proper time advances.

But we can label any curve -- or segment of a curve -- any way we want as coordinates are not physical. It's just that proper time is exceptionally useful as a coordinate. In particular, it satisfies the geodesic equation, gives us a four-velocity, which multiplied by the object's Lorentz-invariant mass gives us a four-momentum.

Unfortunately proper time is undefined on non-timelike geodesics, so can't be used for light, which in vacuum is always on a null geodesic.

However, there are functions that have the same features as proper time, namely monotonicity, uniqueness, and the preservation of the parallel-transported tangent vector. These are affine parametrizations. Proper time is an affine parametrization for timelike geodesics, and is usually denoted τ; null affine parametrizations which satisfy the geodesic equation are usually denoted λ.

We just can't use τ on null geodesics, since it is zero everywhere along one (so non-unique, and non-advancing). Statements based on the use of τ like "light experiences no time" or "light's path is infinitely length-contracted" improperly imply the use of τ.

However, if we use affine time λ, we get uniqueness, monotonicity, and the preservation of the tangent vector under parallel transport. The first derivative with respect to affine time at a point on the null geodesic lets us define a 4-momentum so we can use the Planck-Einstein relation E = pc = hf = hν = ħω relating the frequencies and wavelengths of photons, and how they redshift and dilate from point to point. (This is especially handy in curved spacetimes, like the expanding one in cosmology or the collapsing one around black holes).

- --

[1] An image may help: drop two dimensions from 3+1 spacetime to give us 2-space we get a tangent plane instead of a tangent volume at each point along a geodesic on a 2-sphere (which meridians on Earth's surface approximate) <https://en.wikipedia.org/wiki/Local_tangent_plane_coordinate...> -- sliding the tangent plane south along the meridian in uniform motion is like advancing the proper time.


In my experience, transcoding works fairly well over NFS (over fiber Internet). Mind you, I didn't try 80+ GiB media files.

I am most interested in that DC power supply. I bought a similar one recently (rgeek brand on aliexpress), but haven't yet dared to connect it yet.

I'm wondering what:

- the failure mode is if it can't provide enough current.

- How to properly test it under a fake load

- If these tiny power cables can really handle 150 W (this is 12 A at 12V). I don't have such a powerful 12V PSU, so I am thinking about adding capacitors to handle transients.

I imagine that it is really built to handle transient peaks to 150 W, with a more reasonable baseline.

Anyway, if anyone knows a good knowledge source for these PSU, I'd be interested.

My initial motication for going with these was:

- hopefully increase my PSU efficiency

- less cable clutter

- hopefully power it from a small DC UPS (there are plenty of "router" UPS sold on the market, though the power rating is a bit low, 18-36 W usually).


I have a RK3588 SBC with 5 HDDs and with a good ATX power source it draws about 24-26W from the wall socket. I tried replacing that with a 5A 12V DC power brick and the power usage increased to 28-30W.

Measurements are not accurate, but comparable. I used a Tasmota smart plug - the same one in both cases.


Thanks for the data point, and the vote of confidence. I do not have the best setup to measure power draw (I just broke my dedicated smart plug), but it it may also increase power draw in my case (20 to 30 W, ERYING M-ITX 12500H + 2 nvme SSDs). Your numbers are impressive for 5 HDDs, are they 3.5"?

Anyway, it may be a transient that I am measuring, as the PC turns off during the boot sequence, after the CPU fan starts revving up. My 5A PSU may not be enough, I'll try limiting the TDP and the power brick.


3x 3.5" and 2x 2.5"

Some power bricks are not up to the specs written on them. Get one of those USB power testers that have a barrel plug too. They're very informative in cases like these.


The parts linked on the post are performing well. If you size them well, the main issue you can run into is inrush current when powering up. You may need a soft start circuit. I know I'm at the limit and may need to add a soft start if I add more fans.

Thanks for the feedback! A triggered power-on seauence for drives and fans makes sense, though I feel like this could also be solved by putting a couple of large capacitors on the 12V power rail (those need to charge as well, obviously, which might be an issue on startup).

A more likely measure, which I recall seeing years ago, is to measure the impedance of the enclosure of the thing you want to protect. If someone tampers with it, you would be alerted. It works at many scales, from a protective metal mesh over your IC to a PC case.

Sure, but I would like to point out that gamenative largely exists thanks to FEX-Emu, which was started at Valve's initiative, and which Valve has stealthily funded since its inception.

This. This is what I am looking for. I remember using iz3d years ago, with their anaglyph renderer. Playing Half Life 2, Halo and others in stereoscopic 3D was a great experience. Dead Space was particularly nice, as the game uses no HUD.

I guess most of it could run as a Vulkan layer?


You can already do a lot of it with ReShade shaders like the aforementioned SuperDepth3D, but it requires a game profile, tons of fiddling and non-incompatibility from the game. Having that shipped as dev-tested profiles with games would be the exact sort of thing that makes proton nice to use on the steam deck

Usually the pixel density is higher in the center of the FOV though (more distortion due to the lenses on the sides). It's what set the original Oculus apart from existing headsets at the time: cheap lenses and correct the distorsiin in software. It's also a feature, as the actual density is better in the center :)

I do wish they used micro-LEDs for that kind of display though. I guess that they could be manufactured at the same time as a metamaterial acting as a lens sitting on top.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: