New Nvidia Cards

[Barney]

But nobody has done it realtime before

iirc Intel did it realtime ten years ago. Though it was done using a server farm rather than locally. Was still realtime raytracing though.

[Whiteball]

...Daniel Pohl started researching real-time ray tracing for games in 2004 during his study of computer science at the Erlangen-Nuernberg University in Germany.
As his master’s thesis, he developed a ray-traced version of Quake 4.
In 2007, he joined Intel’s ray-tracing group.
In 2008, he moved from Germany to sunny California where he continues to research game-related ray tracing...

[Dio]

... and if anyone is at the back of the queue of desktop realtime RT, it's Intel

Although, linking this back to Giles' musings, it kind of illustrates the problem with blue-sky research. It can easily deliver very little, and not be the kind of leg-up that you think it might when the real problem comes along.

[Rhythm]

On a very different note, it's incredible that while Sony and Microsoft are waiting for each other to blink and announce pricing, Nvidia come along with a card that on paper might trounce either console and it's priced at basically exactly the same sort of level we'd be expecting Sony and MS to release for.

I'd already decided that I wasn't going to go console this time round, but Nvidia just made my upgrade path potentially much more cost-effective. Jumping from a 1060 to a 3070 should get me some pretty decent results

[gilesgoat]

Topics I am interested in :

- VR, want to be able to render more and faster per eye ( needs to get lighter / more portable )

- Light Fields : love those Looking Glass displays ( needs 10X more power than VR )

- AR, when devices won't cost $3000 per piece and are still 'meh'

- Lot of documentation, good SDKs, the world *IS NOT* made of UE/Unity only otherwise stop calling them "graphic cards/GPUs" call them "add-ons for Unity/Unreal"

Recognizing that realtime RT is definetely something ( still have to see "how much RT really is and how deep it can get" ) it's like .. "yeah .. ok .. IF I can do in VR too ( at decent frame rates ) "

But yes "something at least a little" dedicated for VR/stuff that has to render "same data" N times with small differences, would be great

[gilesgoat]

... and if anyone is at the back of the queue of desktop realtime RT, it's Intel

Although, linking this back to Giles' musings, it kind of illustrates the problem with blue-sky research. It can easily deliver very little, and not be the kind of leg-up that you think it might when the real problem comes along.

.. when I'll discover something you REALLY want that you have not discovered cause "the blue sky" remember then it's going to cost you THE MOON to have it

[rowan]

What counts as "real time ray tracing" ?
60 fps and never dropping a frame? 30? Whatever fps your application is designed to run at?

Real time is a term I've become very wary of mentioning in the workplace as I work in IT [as in PCs and shite], and there are a number of other beardy types who will argue relentlessly that
* real time is nothing about speed, in fact many real time things are pretty slow. What's important is being able to depend on when results will be available
* nothing really is real time on any PC these days
* this thing here [waving big heavy lump of decades-old electronics in air]: That's real time


I do get what they mean but it's still easier for me to avoid the term if it spares me hearing the above all over again.
I suspect part of the issue is that because they worked on hard-real time systems 20, 30 years ago or more, they believe they know it all and refuse to listen to anyone / anything else about it.

[gilesgoat]

What counts as "real time ray tracing" ?
60 fps and never dropping a frame? 30? Whatever fps your application is designed to run at?

Real time is a term I've become very wary of mentioning in the workplace as I work in IT [as in PCs and shite], and there are a number of other beardy types who will argue relentlessly that
* real time is nothing about speed, in fact many real time things are pretty slow. What's important is being able to depend on when results will be available
* nothing really is real time on any PC these days
* this thing here [waving big heavy lump of decades-old electronics in air]: That's real time


I do get what they mean but it's still easier for me to avoid the term if it spares me hearing the above all over again.
I suspect part of the issue is that because they worked on hard-real time systems 20, 30 years ago or more, they believe they know it all and refuse to listen to anyone / anything else about it.

According to when I was working with OS-9/68K "Real Time" meant "Able to respond to events in a FINITE MAX amount of time", i.e. "comes an interrupt, the interrupt is served in AT MAX N us" it means that there's always a "deterministic time/response/max time" to which events are processed.

This IIRC was "at system level" I mean if you do an SW that makes an infinite loop and stays there forever "that does not count" as long as the OS responds to events in a determined way/time, again IIRC there was a thing about the "interrupt routines" NOT having "queues" and the mem allocator having an algorithm guaranteed to be fully deterministic.

Now "interesting question" "what does it means RT real time" ?

"All and nothing" I think it would be more correct/precise to say "RT HW accelerated" where some computations are NOT done CPU side but "by GPU HW" .. even that is "unclear" because in the end of the day "it's really HW ?" "It's SW running on the GPU ?" "It's microcode ?" .. the answer is probably "ALL OF THE 3" but "the main point" is that "is done entierely GPU side not by CPU intervention".

Now "real time" .. again .. as you say "my game goes 60 FPS" .. I could interpret "real time" as "ALL I NEED TO RENDER IN RT is done in < 16 ms " .. so "the whole game would run real time".

But if my game goes 30 FPS .. then 33ms is "real time" ? .. and if I do VR and I need 120 Hz ? or 90 Hz? Then 16 ms is no longer "real time" because I lag frames ?

But I think we could maybe agree that IN THIS CASE "real time" could mean :

- it's all done GPU side "in some ways"
- ALL that needs to be rendered in RT is done in less than a frame time I need
- I can BOUND and find MIN/MAX rendering times for a given data set so I can TRIM things to attain the 2 above

Said that, "if things are really simple" you COULD do ALL of it purely in SW "no need of GPU acceleration" .. and it still would be "Real Time Ray Tracing".

Questions also could be at this point :

- given let's say 60 FPS
- given a certain resolution
- given a MAX DEPTH of rays ( i.e. how many reflected/refracted rays you can consider after the first intersection )
- given a MAX NUMBER of rays per screen ( 1 per pixel ? Less ? oversampling ? )
- given a MAX NUMBER of primitives ( triangles only ? )
- given some "materials shader"

"You can guarantee the whole scene is rendered always in <= X time". [edit] where in this case 'X' < 16 ms

I'd say "if you can satisfy that" I SUPPOSE we could say "we are real time enough" ?

Really "real time" it's a bit vague as definition.

[gilesgoat]

What counts as "real time ray tracing" ?
60 fps and never dropping a frame? 30? Whatever fps your application is designed to run at?

Real time is a term I've become very wary of mentioning in the workplace as I work in IT [as in PCs and shite], and there are a number of other beardy types who will argue relentlessly that
* real time is nothing about speed, in fact many real time things are pretty slow. What's important is being able to depend on when results will be available
* nothing really is real time on any PC these days
* this thing here [waving big heavy lump of decades-old electronics in air]: That's real time


I do get what they mean but it's still easier for me to avoid the term if it spares me hearing the above all over again.
I suspect part of the issue is that because they worked on hard-real time systems 20, 30 years ago or more, they believe they know it all and refuse to listen to anyone / anything else about it.

I been working for a bit in embedded system/industrial control.

As I said the way they explained me "real time" was that "you can process data always with a finite never > MAX amount of time".

Also I vaguely remember of code that should have been fully relocable and re-entrant.

The "classic example" was "you need to do some signal processing you need to be able to process data as it comes, you can NOT add a "random amount of delay" in the processing if this delay would have "no upper limit" ( i.e. at worst could be "infinite" ) ".

The "classic example" was that "Windows CANNOT DO THAT because CANNOT guarantee this", nor Linux, IIRC there was Lynx-RT for that and/or stuff like QNX or other shit, OS-9 Microware was capable of doing that, even that I THINK there was "a specific RT version" for that.

I remember story went "you have an interrupt routine that when it gets an interrupt HAS to close a valve stopping some shit explode before N seconds after the interrupt" with a NON-Real Time OS you can NOT do that !

It mean it HAS to be "mathematically proven" that the OS CAN do that.

I am INCLINED to think that ALL the 3 things that those beardy type say are PERFECTLY REAL and/or at least WERE in the times they were using those, I STILL think that it's TRUE that a thing like Windows IS NOT "Real Time" nor Linux, not so sure about Mac OSX I know that "at least for certain things" it is.

Again if you CAN GUARANTEE that "given an event X, this gets served *ALWAYS* in NEVER > MAX time" then "that should be real time", if you can not mathematically and physically guarantee that "then it's DEFINITELY NOT" real time.

For example I remember in OS9 an interrupt routine CAN be interrupted by another interrupt, can't remember the details but that's part of what guarantees the RT ( and the re-entrancy and other stuff as the interrupt routine can 'recursively' call itself IIRC ) .

There's something "a bit strange/similar" can be done in Z80 coding as well, I did something with interrupt routines triggering an EI as soon as possible to be re-called again ( sort of recursion ).

[rowan]

Really "real time" it's a bit vague as definition.

There's a fairly good Wikipedia entry these days, describing hard real time, soft real time, firm real time, near real time and a bunch of examples.
They stuck games mostly as soft real time as if things aren't ready in time, there is essentially a degradation in performance rather than critical system failure.
But once you start talking about soft real time & allowing deadline failures, does that mean "something which is supposed to be 60fps which it very occasionally achieves but mostly it's 55ish" is still "real time" ?

So with all that, I guess in a way, I'm actually just parroting the beardy types at work and pointing out the term is often overused or incorrectly used to mean "fast"

Maybe we can stick it back on the shelf between the superfoods & detox until someone invents the next big thing(tm) for graphics cards.

[Dio]

Real time is a term I've become very wary of mentioning in the workplace as I work in IT [as in PCs and shite], and there are a number of other beardy types who will argue relentlessly that
* real time is nothing about speed, in fact many real time things are pretty slow. What's important is being able to depend on when results will be available
* nothing really is real time on any PC these days
* this thing here [waving big heavy lump of decades-old electronics in air]: That's real time

Yeah, that's roughly true. When it comes to gaming, realtime means "99% of the time hitting some kind of deadline that is of the order of 5-30ms, with occasional sustained dips a little longer than that and as few as possible stutters of much longer than that". It's a soft realtime requirement as you say.

A fairly hard realtime on PC is achievable - the compositors do that, VR wouldn't work at all without a hard guarantee that the VR compositor gets about 1ms of the GPU every 10ms-ish. That was a bit iffy in the early days but Microsoft added some stuff to help out (and AMD has always been pretty good about it because we have had quite a flexible concurrency architecture in there since GCN).

[gilesgoat]

*SNIP*

But once you start talking about soft real time & allowing deadline failures, does that mean "something which is supposed to be 60fps which it very occasionally achieves but mostly it's 55ish" is still "real time" ?

*SNIP*

Well .. for the definition that was "real time" at the time I was working with those thing the answer to that would be DEFINITELY NOT !

And it also would be "and if does not do ALWAYS 60fps it's OUT of the specs in the contract !" ( which basically meant you have NOT delivered the job you been asked for, which also meant, you won't get paid, you lost time, you'd have to pay penalties ).

Yes we are talking about "total system failure" in case 60Fps are NOT achieved, tons of money lost per hour if the thing stats to "slip" into 55 or worse.

But it wasn't 60fps or exoteric things, not always, but "mundane" things like "this thing controls a switch via a PLC that deviates some merchandise running in a conveyor belt from one place to another and if it's not perfectly synchronized on time packages start falling down" - THIS HAPPENED FOR REAL cause a SW / HW glitch they had to stop one of the "lines" with DIRE consequences and people taking a car and running like crazy from Trieste to Milan to check WTF was going on (*)

Those were the times and situation that if you would have mentioned "we could use Windows for .." .. you were fired on the stop ( and probably got on the way out another lecture on 'real time' )

(*) fun facts, that was a line controlling stuff on an Alessi distribution thing, that Alessi that sells "weird things at incredibly high prices" like "Il Merdolino" and "Spider lemon squeezers" and stuff like that. They have a pretty complex system of conveyor belts , machines, all automated moving packages/stuff all over controlled by a mixture of PLCs, serial lines in noisy envirronements, can't remember what else SW cause I did not work on it but I was hearing the stories. The big problem was "doing simulations" of that stuff because there were "many mechanical issues" in place like "you have to see/trim some stuff on the place to see how it goes" ( those were 199X also, no big SWs to help ). So one day we get quite a frantic phone call that "there's something wrong with the new lines", there was this thing occasionally "flipping pacakges out of the line" and the problem was they were falling down a height of 10 meters or such with the risk of breaking the stuff inside ( mostly was metallic stuff but not all of it ). So because it was "occasionally but frequent enough" they did not want to stop the whole line ( that would have been DISASTER ) so they put some guys down there "waiting to catch on the fly the parcels that were falling down" but "they could not let them stay for too long" So someone took a laptop, some SW and 3 of them jumped in a car and took a 4 hours drive ( I think they done it in 3 speeding real fast ) to go to Milan and fix the thing. I think turns out it was all due a "delay" between a sensor and the activation command or some shit like that.

"Real time"

[Jamesac]

Heresy time- If the effect is obvious and popular enough, "real time" = 30-ish frames per second. There may be some forum grumbling but the marketing department can sell that, even with the occasional dip below.

[gilesgoat]

Heresy time- If the effect is obvious and popular enough, "real time" = 30-ish frames per second. There may be some forum grumbling but the marketing department can sell that, even with the occasional dip below.

.. tell them to those gamers spending $3000 (*) on a "pro gaming KB" to have faster response and those "Freesynch/G-Synch" 240Hz monitors to have "an edge" while playing those FPS that complain "why Moose Life does not work with their 4 monitors setup" and maybe use those "Razer something pro mouse" costing another $1000 or such ..

(*) that they smash on a fit of rage while streaming and losing at Fortnite.

Nor Nvidia, nor AMD nor Intel seems to have YET understood that REAL TIME RAY TRACING IS *NOTHING* *IF NOT* coupled with a bunch of RGB LEDs that glow on the graphic card, if the graphic card does NOT have customiseable "face plates" with some weird logo and/or an anime girl in sexy pose with HUGE b00bi35 , I repeat they need the next CPU encased in a QUARTZ case ( with RGB leds that throb as the gpu 'does something' ) "turbo liquid/vapour cooling system" - COLOURED - possibly colour changing !

"Their market" for THAT "realtime RT" is the market that buys this :

https://i.ebayimg.com/images/g/9TEAAOSw ... s-l640.jpg

Puts this kind of stuff on the GPU :

https://i.etsystatic.com/17310602/r/il/ ... 5_gc1j.jpg

Uses memory like this :

https://www.overclockers.co.uk/corsair- ... gLTvPD_BwE

Have cases like that :



Compete in this sort of things :



Real time ray tracing ? ... no no no no .. it's ALL ABOUT RGB LEDS man !!

[PVB]

I’m currently looking at getting a desktop gaming PC.

I am completely bewildered by even ‘professional’ PC gaming sites promoting PCs with lots of ‘RGB’ lighting inside the case.

I’m finding it difficult to find any PCs that don’t look like Las Vegas at night.