It can be rather difficult, mostly due to the occlusion calculations having to be conservative (must count visible things as visible, allowed to count invisible as visible, or things pop) and latency (must account for every possible position within max move speed * max latency, or things pop)
The naive raycast from player camera to other player would be fine for perf but may count partially visible as invisible, so its unacceptable. You'd have to raycast every pixel of the potentially visible player model to stay conservative. With movement + latency this expands to every pixel the player model could potentially occupy during your max latency period, and you need to consider the viewer moving too!
In practice this expands to a visibility test between two spheres with radius max_latency*max_movespeed + player_model_radius. Now, you could theoretically do a bunch of random raycasts between the spheres and get an answer that is right some of the time, but it would be a serious violation of our conservativeness criteria and the performance would get worse with more rays/better results. Also keep in mind that we need to do this for every single player/player pair a few dozen times per second, so it needs to be fast!
To do this, you need a dedicated data structure that maps volumes to other volumes visible from said volume. There are a few, and they are all non-trivial and/or slow to build well. (google for eg. potentially visible set, cell-portal graph + occlusion). You also trade performance for precision, and in practice you walls might become 'transparent' a bit too early. With all this being done, we can actually "do occlusion calculations server-side".
There's just one problem with this that I still don't know a solution for, namely precision. With fast players and imprecise conservative visibility, things you care about are going to count as visible pretty often, including stuff like enemies peeking from behind a corner (because they could have moved at full sprint for 100ms and the end of the wall is rounded away in your acceleration structure anyway) so all this complexity might not get you that much, particularly if your game is fast paced. You'd prevent some wallhacks but not the ones that really matter.
TLDR yes, it's actually hard and might not be good enough anyway
Just write a 10 TB hard disk full of plaintext mantras and let that bad boy spin at its usual ~5k rpm for a cost effective 50 PB of mantras per minute. Or go MAAS and write a few them into S3.
I'd say `x * a + (x * x) * b + (x * x * x) * c` is likely faster (subject to the compiler being reasonable) than `((((x * c) * x + b) * x) + a) * x` because it has a shorter longest instruction dependency chain. Add/Mul have higher throughput than latency, so the latency chain dominates performance and a few extra instructions will just get hidden away by instruction level parallelism.
Also x/6 vs x(1/6) is not as bad as it used to be, fdiv keeps getting faster. On my zen2 its 10 cycles latency and 0.33/cycle throughput for (vector) div, and 3 latency and 2/cycle throughput for (vector) add. So about 1/3 speed, worse if you have a lot of divs and the pipeline fills up. Going back to Pentium the difference is ~10x and you don't get to hide it with instruction parallelism.
* The first expression has a chain of 4 instructions that cannot be started before the last one finished `(((x * x) * x) * c) + the rest` vs the entire expression being a such a chain in the second version. Using fma instructions changes this a bit, making all the adds in both expressions 'free' but this changes precision and needs -ffast-math or such, which I agree is dangerous and generally ill advised.
Baseline time to grok something looks to be around 1000x normal training time so make that $20k per attempt. Probably takes a while too. Their headline number (50x faster than baseline, $400) looks pretty doable if you can make grokking happen reliably at that speed.
For a bit of reference, a full frame of Crysis (benchmark scene) was around 300k vertices or triangles (memory is fuzzy), so 3-10 log piles depending on which way my memory is off and how bad the vertex/triangle ratio is in each.
The framing here is a little unfair, its DLSS that does not support AMD hardware, not the other way around. This is clearly a deliberate decision by Nvidia. Meanwhile AMD/FSR supports both AMD and Nvidia hardware.
Sounds like using the wrong metric, the upscaled image should be compared against the original full resolution one, not the downscaled one. Obviously you can't know what the full resolution one looks like when actually upscaling (vs testing), but you can make an educated guess.
That list is only really useful for major styles that are well known/tagged, early SD versions knew a list of artists _much_ longer and more relevant than that. (some of the styles on that list are not related to 2d images). If you consider the list a reasonable substitute for artist names, I'd ask you for a prompt that replicates the common Rutkowski + Mucha style using just the styles listed.
>> It's almost as if artists develop their own styles that are just as uniquely theirs
Hard disagree on this. Styles do not and should not have ownership, legally or otherwise. Not in painting, music, film, games, or any other kind of art. Anything else kneecaps derivative styles and erects a massive barrier to the advancement of culture. Straight copies are mostly avoided because they add nothing over the original.
You're also misunderstanding the typical use of Rutkowski and other names. Most prompts I've seen and used use multiple artists for a unique blend of styles (including the much maligned and overused Rutkowski + Mucha), not just straight copies. While asking for Rutkowski indeed asks for a very specific style (as well as any themes etc common to his work), its usually in combination with other equally specific and somewhat contradictory styles, each guiding the result in some direction and adding elements but none of them being exactly the desired end result. Just asking for straight up Rutkowski was a short lived cargo cult and is now more of a meme than anything else.
The thing is, most styles don't have names, only artists using them. If you remove artist names from the training data, you lose the ability to describe those styles, including as combinations (so you can't even do "influenced by rutkowski" styles). This obviously sucks for the user, and I don't think artists should be able to deny control over style just because it makes imitation easy.
In this context, putting an artist back in the model is a pretty sensible form of disagreement/protest. I admit the "I'll take this down if they ask me to" is strange, but mostly because its too weak; the LoRA should just stay up, not demand another no from someone who already made their opinion clear.
You have chroma and luma the wrong way around, chroma is color and luma is light intensity. Chroma is still the thing being subsampled.
I've never really noticed effects from chroma subsampling so my guess would be the bitrate just being better with the higher resolution. Also "full res->compress->downsample" might be more efficient than "full res->downsample->compress" since downsampling is a (really bad) form of lossy compression as well.
So I took a look at the actual shader, and it really should not require anything powerful (decade old, worst-you-can-get hardware might struggle). A much more likely explanation (that the gp is alluding to but didn't explicitly say) is that the issue is related to your GPU drivers or related software. These are often buggy and/or hit a slow path for whatever reason. This is almost guaranteed to happen for some browser/os/hardware/driver combo (of which there are _many_) and you seem to have drawn today's short stick.
The animation itself looks fine, its slow enough that it doesn't feel distracting. Just a bit of flavor.
Its mostly just a few calls to a cheap noise function and no footguns I can see. Also hurrah for dev tools and open text formats! If you're looking for better performance, it looks like the noise could be precomputed (the same blob always gets the same noise)". Might be faster, might just hit more bugs.
Not quite ELI5 and there's a few partially overlapping answers around already but here goes.
The key part is the attention mechanism, as title of the paper may have spoiled. It works moreless like this:
- Start with an input sequence X1, X2 ... Xn. These are all vectors.
- Map the input sequence X into 3 new sequences of vectors: query (Q), key (K), and value(V), all of the same length as the input X. This is done using learnable mappings for each of the sequences (so one for X->Q, another for X->K and one for X->V).
- Compare similarity of every query with every key. This gives you a weight for each query/key pair. Call them W(Q1, V2) and so forth.
- Compute output Z as sum of every _value_ weighted by the weight for the respective query/key pair (so Z1 = V1W(Q1,K1) + V2W(Q1,K2) + ... + VnW(Q1,Kn), Z2 = V1W(Q2,K1) + V2*W(Q2,K2)...)
- and that's about it!
As throwawaymaths mentions, this is quite similar to a learnable hash table with the notable difference that the value fetched is also changed, so that it doesn't fetch "input at an index like i" but "whatever is important at an index like i".
Now a few implementation details on top of this:
- The description is for a single "attention head". Normally several, each with their own mappings for Q/K/V, are used, so the transformer can look at different "things" simultaneously. 8 attention heads seems pretty common.
- The description doesn't take the position in the sequence into account (W(Q1,K1) and W(Q1,Kn) are treated perfectly equally). To account for ordering, "positional encoding" is normally used. Usually this is just adding a bunch of scaled sine/cosine waves to the input. Works surprisingly well.
- The transformer architecture has a number of these "attention layers" stacked one after the other and also 2 different stacks (encoder, decoder). The paper is about machine translation, so the encoder is for the input text and the decoder for the output. Attention layers work just fine in other configurations as well.
The rest of the architecture is fairly standard stuff
If consciousness is binary like you state, we can hypothetically remove parts of it until we reach some arbitrarily small part after the removal of which the remainder is no longer conscious. This seems like a very weak argument to me, implying the opposite conclusion that consciousness must be on a sliding scale.
(measuring the level of consciousness is left as an exercise to the reader)
The problem here is the definition of real, which is ultimately a matter of perspective. What is simulated rain to an external observer is real rain to one that only sees the simulation from within. In this sense real rain can be just computation.
Also by the article's definition, a simulated consciousness (should it somehow exist) is no less real since only the consciousness' own qualia matters and the hypothetical simulated consciousness must have one by definition.
Based on some quick* testing using z-order instead of going row by row ends up taking 1-10% less space. Most images were on the lower end but I didn't run into any taking more space.
* Swapping to z-order requires about 5 lines of changes if you ignore all the little edge cases like non power-of-two image sizes. Images used in testing may or may not be representative of anything.
Having a few false negatives in the control group shouldn't really matter since that would only make the groups more similar and hide any differences that exist rather than hallucinating ones that don't.
We have pieces of code at (gaming related) work that have very tight, and carefully thought out, error bounds (think 4 ULP) and can certainly break if float rounding doesn't work as expected. I'd expect a physics engine to contain plenty of similar code, particularly related to collision detection. Rendering and gameplay logic are probably a bit less picky
I don't have a good article on this but I'd assume the rocket delivers the satellites to an orbit slightly below the target one. The satellites can then move to the final orbit on their own (small transfers take much less energy than one might guess). Since lower orbits are faster than higher ones spacing on the final orbit can be controlled by the timing of the final transfer.