[Dag]

I'm sorry to argue with you, sebbbi: you're a very intelligent person. Still, if you have followed Mr. Dell you will agree that he hardly did read anything about octrees. He discovered them, maybe in trying to cull/distribute points among the view frustum's subfrusta (corresponding to viewplane quadrants) faster (perhaps the primeval rendering scheme: a bucket sort where the frusta are the buckets).

There's no animation either. Not a single moving object is present (not even simple rigid bodies instead of complex skinned models).

In fact, already in its early stages, UD had animated characters (quite a feat, actually).

completely static (it doesn't feel realistic at all)

More detailed volumetric data + high frame rates completely floors the unjustly fashionable and untrue eye candy + destructible environment: kinetic depth effect.

[Rodéric]

Originally Posted by Dag

I'm sorry to argue with you, sebbbi: you're a very intelligent person. Still, if you have followed Mr. Dell you will agree that he hardly did read anything about octrees. He discovered them, maybe in trying to cull/distribute points among the view frustum's subfrusta (corresponding to viewplane quadrants) faster (perhaps the primeval rendering scheme: a bucket sort where the frusta are the buckets).

Are you saying we should congratulate him because he didn't even do his homework and reinvented the wheel ? Seriously ?

Originally Posted by Dag

In fact, already in its early stages, UD had animated characters (quite a feat, actually).

I believe there's a video online showing a few animated things in isolation. (Likely because it can't run fast in a landscape.)

Originally Posted by Dag

More detailed volumetric data + high frame rates completely floors the unjustly fashionable and untrue eye candy + destructible environment: kinetic depth effect.

That's an opinion, other people will disagree, destructible environments in Battlefield change the dynamic of the game a lot.

Anyway if he wants to be taken seriously he must get a patent, publish his algorithm and be done with all this nonsense.

[Dag]

Are you saying we should congratulate him because he didn't even do his homework and reinvented the wheel ? Seriously ?

Of course.

Let me therefore beg of thee not to trust to ye opinion of any man concerning these things, for so it is great odds but thou shalt be deceived. Much less oughtest thou to keep to rely upon the judgment of ye multitude, for so thou shalt certainly be deceived. (I. Newton)

J'ai souvent remarqué, que des personnes, qui ne font pas tout à fait profession du métier, ont coutume de fournir des pensées plus singulières, concetti più vaghi et più pelegrini, où l'on ne s'attend pas... une personne qui n'était pas géomètre du tout et qui fit imprimer quelque chose de géométrie donna quelque occasion à ma quadrature arithmétique, sans parler d'autres exemples. (G. W. Leibniz)

Beginning in the late '90s, the focus shifted from HSR – the noblest part of CG – to a multitude of texturing schemes (poudre aux yeux) and everybody was complying with the SGI style of doing 3D. The result is what we have today, an ugly body (texture mapped triangles) in pompous robes (effeminate eye candy). This is an example of the bad effects of GPUs.

Anyway if he wants to be taken seriously he must get a patent

http://www.ipaustralia.com.au/applic.../AU2012903094/

[jlippo]

Originally Posted by Dag

http://www.ipaustralia.com.au/applic.../AU2012903094/

Is there any place where we might actually get the proper information about the algorithm?

I have tried to follow UD for a while and the released information hasn't been encouraging.
Especially as it has been around for a ~10 years..

[Dag]

Originally Posted by jlippo

Is there any place where we might actually get the proper information about the algorithm?

Not that I know of. But there are bits here (literally) and there, enough for an unprejudiced programmer.

[Dag]

Here: http://forum.beyond3d.com/showthread...41#post1676041
There: http://www.gmscript.com/gamemonkey/f...12&t=419#p2049

[Nick]

Originally Posted by Davros

So why have the iGPU ?

Rome wasn't built in a day.

will it have more gflops than a dedicated gpu of 2013 ?

That depends on which CPU and GPU you're comparing exactly.

Nick is Mr SmartShader

That's ATI's marketing term for their Shader Model 1.4 hardware. I'm not sure if I should feel flattered or a little insulted.

[Nick]

Originally Posted by ERP

Honestly I think you'd see more games that looked the same with CPU based rendering.

You'd reduce the pool of programmers capable of writing a good renderer even further (and it's not a deep pool now), most people would just defer to middle ware. Those that didn't would probably write once and use many times.

I'm sorry but that is clearly false. Applications that don't use/need the GPU overall don't look/feel very alike, despite having much more low-level access to the CPU. There's really no reduction of the pool of programmers capable of creating something valuable. There's just more of a split between low-level, middle-level and high-level development. You don't have to know x86's encoding format to be part of some innovative application development. Only a handful of compiler programmers do.

Likewise, making the GPU more programmable has never led to games that look more alike. It's certainly true that it has caused a shift from everyone using the API directly, to more people using middleware, but there's more diversity among this middleware than among the legacy APIs.

I think you have to ask what it is you want to do with your CPU renderer that you can't do on a GPU?

It's futile to ask that. It reminds me of discussions on forums like these about what people would do with floating-point pixel processing, back in the GeForce 3 days. John Carmack had a few ideas but many considered that not to be worth the transistors. We now know that what Carmack had in mind was just the tip of the iceberg of what can actually be done with the technology. It's utterly unthinkable to have a GPU without floating-point pixel processing today. So don't worry too much about what the unification of CPU and GPU can result into specifically. There will be a revolutionary application for everyone.

[Blazkowicz]

Originally Posted by Dag

I'm sorry to argue with you, sebbbi: you're a very intelligent person. Still, if you have followed Mr. Dell you will agree that he hardly did read anything about octrees. He discovered them, maybe in trying to cull/distribute points among the view frustum's subfrusta (corresponding to viewplane quadrants) faster (perhaps the primeval rendering scheme: a bucket sort where the frusta are the buckets).

In fact, already in its early stages, UD had animated characters (quite a feat, actually).

More detailed volumetric data + high frame rates completely floors the unjustly fashionable and untrue eye candy + destructible environment: kinetic depth effect.

If you want an artistic and static environment, Rage's megatexturing is already working, you can go license id tech 5 and make a 100GB game if that's what you want (assuming id/bethesda would be open to negociation for you).

UD did not talk much about storage requirements, a tech demo with a dozen assets procedurally copy pasted is fine but how much data do you need for reasonable game content : 20GB? 100GB? 1TB?

[Nick]

Originally Posted by Grall

Oh, I think it's a lot more than that, mainly that GPUs aren't just very wide...

Yes there's more involved than gather support. I just said that it's currently the main reason why there's still a large gap between CPUs and GPUs for graphics workloads. AVX2's gather support won't close that gap entirely, but it will make software rendering adequate for far more applications. And like I also said, AVX can be extended up to 1024-bit. There really is no reason the CPU can't become as "wide" as the GPU.

...but also that they pipeline everything extremely effectively. There's no way in hell you're going to be able to hide memory latency effectively enough on a CPU to get near performance of a GPU...

CPUs are doing absolutely fine at dealing with memory latency with out-of-order execution, large caches, prefetching, and 2-way SMT. Especially for something as regular as graphics, it's a non-issue. In fact it's really the GPU you should be worried about. A modest amount of memory access irregularity can cause the GPU's cache hit ratio to drop to zero, causing it to be bottlenecked by bandwidth, register space, or work size. The CPU can deal with increasing complexity very elegantly.

If the latency hiding really isn't good enough, there's always the solution of executing ultra wide vector instructions on less wide execution units. That would also benefit power consumption.

...even if latency wasn't a problem - well, you're still only doing one stage of work at a time on a CPU, while a GPU works on many stages at once. Texture address generation, geometry setup, clipping, texture filtering, shading and so on... All parallel. Serial, on the CPU.

By that reasoning GPU manufacturers should bring back separate vertex and pixel pipelines, because then more things would run in parallel, right?

The fact that things have to be done serially is not an issue in and of itself. Unified processing of the programmable graphics pipeline stages on the GPU has even enabled higher performance through better balancing, and a wide range of new possibilities. It is certainly true that additional CPU performance is needed to cover for fixed-function functionality, but I can tell you it's relatively minor, some of it can be assisted by a handful of new instructions, there are benefits to the additional programmability itself, and again there is still huge untapped potential for increasing the CPU's throughput.

I don't see how you could possibly get remotely similar performance at the same quality level.

I feel sorry for you.

I'm not into arguing semantics.

The point was that based on your wording you probably have a wrong idea about software rendering. It's not an emulation. It's an implementation. In fact it's really hardware rendering, since the CPU is hardware too. Unless there's no confusion about that, we should call it GPU rendering and CPU rendering instead.

[milk]

I think it is reasonable to think that if today's cpu architacture was more efficient then gpu's, amd, ati, game consoles, smartphones and the like would be using them intead.

[Nick]

Originally Posted by willardjuice

Because despite what certain individuals tell you, avx2 will not make CPUs adequately equipped to handle complex 3D rendering.

I assume you're talking about me? I never actually said that AVX2 will make the CPU adequately equipped though. Haswell is a monumental step forward, by bringing several important pieces of programmable GPU technology into the CPU cores, but it's only the beginning.

I will make one bold claim about AVX2 though: it means the end of GPGPU in the consumer market.

It also seems a little misguided that you're talking about "complex" 3D rendering. The CPU can handle 3D rendering that is far more complex than the GPU can handle. Performance-wise the gap between the CPU and GPU was much larger when the rendering was still fixed-function. In relative terms the CPU is better at rendering Crysis 2 than it is at Max Payne 2. So the gap is closing, and more complex rendering is in favor of the CPU. Unreal Engine 4 will even spend the majority of time on general compute algorithms, rather than the traditional graphics pipeline.

[Nick]

Originally Posted by Davros

Thats if it amounts to anything

It doesn't necessarily have to amount to anything.

People are trying a lot of different things beyond mere polygons today. But they're limited by the GPU's inflexibility and by the CPU's throughput. Fixing either problem, or both, means a convergence between the two architectures, which eventually will lead to unification.

So don't base your conclusions about the hardware, on the success of one algorithm. There are countless possibilities and some will be more successful than others. They all point in one direction though.

[Davros]

Originally Posted by Nick

That's ATI's marketing term for their Shader Model 1.4 hardware. I'm not sure if I should feel flattered or a little insulted.

Oops, mr SwiftShader.
on a related note Amd should bring back smartshaders especially HdRish wich was awesome.

[Nick]

Originally Posted by Blazkowicz

But what is this "CPU" that is worth using? Let's say nvidia Maxwell, Haswell/Broadwell successor, Steamroller successor meet a loose definition of a heteregeneous CPU. They are CPU+GPU but the GPU gets a lot CPU-like (even Tesla K20 seems meant to run "software" and not "shaders").

You have to write your program three times, each time catering to the architecture so you get high performance (given real time constraints and big workloads). For added fun, one has ARM, and CUDA libraries, the others have x86-64, AMD has a "HSA" ecosystem, Intel I don't know what they will be doing.

No, you don't have to write your program three times. You just compile it for a different ISA, and let the compiler figure out the details of optimizing for the architecture. AMD is thinking of using HSA as a virtual homogeneous ISA, but that will fail miserably if they keep the CPU and GPU heterogeneous, since compilers can't deal with that and application developers don't want to deal with that. What is needed instead is cores that combine a legacy scalar CPU core and a very wide SIMD engine, which both feed off the same physically homogeneous instruction stream. Intel announced the VEX encoding to be extendable to 1024-bit from the start, and they seem to be pretty well en route with Haswell.

[Blazkowicz]

Originally Posted by milk

I think it is reasonable to think that if today's cpu architacture was more efficient then gpu's, amd, ati, game consoles, smartphones and the like would be using them intead.

Or we would at least have an occasional voxel-based PC game, or game liberally using arbitrary software rendering code.

[Davros]

I just tried Ati SmartShader on the off chance it still worked, It doesnt

[milk]

Originally Posted by Blazkowicz

Or we would at least have an occasional voxel-based PC game, or game liberally using arbitrary software rendering code.

Well, to counter-argue ourselves, there is this...

[Davros]

And this

[Dag]

As of April 23, Battlefield 4. (That may, hopefully, have changed).

[3dilettante]

Originally Posted by 3D_world

The future of 3D rendering:

• Fast - 4 ghz
  Complex - out-of-order instruction dispatch, massive caches
  Not massively parallel - 12-24 cores

Whatever future date this is, trends within the forseeable future do not point to this being feasible for consumer-level real-time graphics.
If Intel's near-threshold computing works out, it pushes for a stronger bifurcation between the throughput-oriented logic and the high-speed logic.
Fast cores will not tolerate the changes made to allow for extremely low-voltage operation, while throughput-oriented cores and logic will favor parallelism, since they may not clock very high individually but will require very, very little power.

As aggravating as the GPU on chips like Sandy Bridge and the like may be to some, it simply provides more utility for the user than a few more high-speed cores they won't use, and it does so within a much more confined power and die budget.
With mobile and cloud computing overtaking the thermally-maxed client PC market as a driving force for development, this doesn't look to change in the near term.

There is some possibility for a Larrabee-type solution of small throughput cores being put on the same die as powerful OoO heavies, which has been on Intel's to-do list for probably going on a decade now. It seems like it almost made it at some point before delays or the competitiveness of the IGP won out. Even with this, the likely demands on the silicon and how Intel has accepted the use of specialized logic when it is needed point to the idea of a dozen or so OoO core monster chip as the future of rendering not being likely for the next 2-3 silicon nodes. We are running out of those, by the way.

[Rodéric]

Originally Posted by Davros

And this

Best game ever.

[milk]

And there we go. Outcast. It took just two pages.

[Osamar]

Originally Posted by Rodéric

Best game ever.

Sorry for the semi-off topic.

It could be possible to "patch" Outcast with an improved voxel renderer for higher resolution using modern CPU or even a GPU voxel renderer?

Just, mind flying.

[Voxilla]

Originally Posted by Osamar

It could be possible to "patch" Outcast with an improved voxel renderer for higher resolution using modern CPU or even a GPU voxel renderer?

As it just renders a height field no true voxel rendering is needed. Long time ago I made a prototype to render the height map with polygons (using CPU based depth adaptive tessellation). It ran pretty fast, on those now ancient GPUs (besides much better image quality)