Originally posted by lizardbones

It does sound like from what you said the Tegra 4 will do more than the Tegra 3 though. It won't just be faster, it'll have more features. So that answers some of my wondering. The chip will do more than the previous generation, it won't just be faster. That's enough of a reason to be a compelling reason to buy into a Tegra 4 based device for some sort of gaming. Not a tablet, but maybe an Android MiniPC or the Shield.

 

As compared to Tegra 3, I have the impression that Tegra 4 will have basically the same API support, but just has a lot more hardware to throw at it.  Sometimes that makes things viable that weren't before.  Radeon HD 6250 integrated graphics fully support DirectX 11, and if you run a demanding DirectX 11 game on them with all settings maxed, it likely will run the game.  (It's not guaranteed to run; sometimes slow hardware will cause crashes because it triggers corner cases that the developers didn't anticipate.)  But if you're only getting 2 frames per second and want to actually play the game rather than just testing to see if it runs, it can't do that--but a faster GPU based on exactly the same architecture could.

Originally posted by Zeblade
Nothing like taking a random thought and running with it. So where does all this info come from? "I read it from someone that heard someone talking that heard it from a phone call that was reading it off the internet". Try to remember where your reading this at.. just saying.. have fun.. haha

http://www.anandtech.com/show/6666/the-tegra-4-gpu-nvidia-claims-better-performance-than-ipad-4

It comes from reporting on Nvidia CEO Jen-Hsun Huang's presentation at CES.

---

Originally posted by Quizzical

---

Originally posted by lizardbones It does sound like from what you said the Tegra 4 will do more than the Tegra 3 though. It won't just be faster, it'll have more features. So that answers some of my wondering. The chip will do more than the previous generation, it won't just be faster. That's enough of a reason to be a compelling reason to buy into a Tegra 4 based device for some sort of gaming. Not a tablet, but maybe an Android MiniPC or the Shield.  

---

As compared to Tegra 3, I have the impression that Tegra 4 will have basically the same API support, but just has a lot more hardware to throw at it.  Sometimes that makes things viable that weren't before.  Radeon HD 6250 integrated graphics fully support DirectX 11, and if you run a demanding DirectX 11 game on them with all settings maxed, it likely will run the game.  (It's not guaranteed to run; sometimes slow hardware will cause crashes because it triggers corner cases that the developers didn't anticipate.)  But if you're only getting 2 frames per second and want to actually play the game rather than just testing to see if it runs, it can't do that--but a faster GPU based on exactly the same architecture could.

---

Originally posted by lizardbones

 

---

Originally posted by Quizzical

---

Originally posted by lizardbones It does sound like from what you said the Tegra 4 will do more than the Tegra 3 though. It won't just be faster, it'll have more features. So that answers some of my wondering. The chip will do more than the previous generation, it won't just be faster. That's enough of a reason to be a compelling reason to buy into a Tegra 4 based device for some sort of gaming. Not a tablet, but maybe an Android MiniPC or the Shield.  

---

As compared to Tegra 3, I have the impression that Tegra 4 will have basically the same API support, but just has a lot more hardware to throw at it.  Sometimes that makes things viable that weren't before.  Radeon HD 6250 integrated graphics fully support DirectX 11, and if you run a demanding DirectX 11 game on them with all settings maxed, it likely will run the game.  (It's not guaranteed to run; sometimes slow hardware will cause crashes because it triggers corner cases that the developers didn't anticipate.)  But if you're only getting 2 frames per second and want to actually play the game rather than just testing to see if it runs, it can't do that--but a faster GPU based on exactly the same architecture could.

---

If a person has a Tegra 4 device, and a Tegra 3 device, and the experience is almost exactly the same, why would they dump their Tegra 3 device for the Tegra 4 device? Why would they add a Tegra 4 device? Games run fine on the current crop of hardware. I don't think they are even straining the edges of what the current hardware can do. Even regular applications aren't really pushing what the current crop of hardware can do.

I don't think developers are going to try and push what the hardware can do unless something like the Tegra 4 is common. They would have a really limited market. Nvidia would have to pay developers to write games or applications that need the Tegra 4's power or people who buy Tegra 4 devices would have to be willing to pay a lot more for Tegra 4 games. It's a solution to a problem that doesn't exist yet.

That's kind of like saying that there's no need for a faster console because Xbox 360 games run fine on an Xbox 360.  Or going back quite a while, that there was no need for a faster console than an NES because NES games ran fine on an NES.  The games that didn't run fine weren't created, precisely because they wouldn't have run well.

If you're planning on tossing any product that you buy today in the garbage six months from now, then maybe you don't need a faster product.  But a faster product with better API support might well be able to run games smoothly that you want to pick up two or three years from now, while a slower product won't be able to.

---

Originally posted by Quizzical

---

Originally posted by lizardbones  

---

Originally posted by Quizzical

---

Originally posted by lizardbones It does sound like from what you said the Tegra 4 will do more than the Tegra 3 though. It won't just be faster, it'll have more features. So that answers some of my wondering. The chip will do more than the previous generation, it won't just be faster. That's enough of a reason to be a compelling reason to buy into a Tegra 4 based device for some sort of gaming. Not a tablet, but maybe an Android MiniPC or the Shield.  

---

As compared to Tegra 3, I have the impression that Tegra 4 will have basically the same API support, but just has a lot more hardware to throw at it.  Sometimes that makes things viable that weren't before.  Radeon HD 6250 integrated graphics fully support DirectX 11, and if you run a demanding DirectX 11 game on them with all settings maxed, it likely will run the game.  (It's not guaranteed to run; sometimes slow hardware will cause crashes because it triggers corner cases that the developers didn't anticipate.)  But if you're only getting 2 frames per second and want to actually play the game rather than just testing to see if it runs, it can't do that--but a faster GPU based on exactly the same architecture could.

---

If a person has a Tegra 4 device, and a Tegra 3 device, and the experience is almost exactly the same, why would they dump their Tegra 3 device for the Tegra 4 device? Why would they add a Tegra 4 device? Games run fine on the current crop of hardware. I don't think they are even straining the edges of what the current hardware can do. Even regular applications aren't really pushing what the current crop of hardware can do. I don't think developers are going to try and push what the hardware can do unless something like the Tegra 4 is common. They would have a really limited market. Nvidia would have to pay developers to write games or applications that need the Tegra 4's power or people who buy Tegra 4 devices would have to be willing to pay a lot more for Tegra 4 games. It's a solution to a problem that doesn't exist yet.

---

That's kind of like saying that there's no need for a faster console because Xbox 360 games run fine on an Xbox 360.  Or going back quite a while, that there was no need for a faster console than an NES because NES games ran fine on an NES.  The games that didn't run fine weren't created, precisely because they wouldn't have run well.

If you're planning on tossing any product that you buy today in the garbage six months from now, then maybe you don't need a faster product.  But a faster product with better API support might well be able to run games smoothly that you want to pick up two or three years from now, while a slower product won't be able to.

---

Originally posted by lizardbones

A new console wouldn't just be faster though. It would have more features. We ended up with N64s because they added more features and options that didn't exist until the N64s were created. People weren't buying N64s to play NES games, they were buying N64s to play N64 games with N64 features. The Tegra 4 isn't doing this. I went and looked it up and other analysts are saying what you're saying. The Tegra 4 is definitely faster, but it's not doing anything new.

Now, the rest is my own analysis, such as it is. The Tegra 4 doesn't add any new features, and there is also no need for faster processors. Games like Pocket Legends and Minecraft PE that run fine on my Nook 16gb run fine on my old HTC phone. They also run fine on my brand new Motorola phone. My phone has a better processor than my Nook, and way better than my old HTC phone, but my experience is the same on all these devices. What's my incentive for picking a Tegra 4 device over another, cheaper device? Unless Tegra 4 is the only option in the device I'm picking, there's no particular reason to gravitate there. I would choose based on my experiences with HTC and Samsung, and choose between those vendors rather than looking for a Tegra 4 device. It seems to me that a lot of other consumers would do the same thing.

As graphics APIs go, features and performance are sometimes interchangeable.

Any 3D image that you can create in a modern game, you could likely create on a Silicon Graphics workstation running OpenGL 1.0 twenty years ago (monitor resolution or system memory capacity would block some things, though I'm not sure exactly what--but the API on its own wouldn't).  If you're using graphical features today that didn't exist then, you could do the computations on the CPU instead of the GPU to work around it.  What you couldn't do then is to run something with graphics on par with, say, WoW, at 60 frames per second.  Or 1 frame per second.  Likely not 1 frame per minute, either.

Having the modern APIs and hardware means you can render things much faster.  It likely also makes things much easier to code.  It doesn't make possible things that were previously impossible, but it does make them practical.

But more brute force performance also makes more things practical.  Even if a 1 MHz GPU chip with 1 shader, 1 TMU, 1 ROP, and 1 of everything else that is essential to a GPU chip were fully OpenGL 4.3 and DirectX 11.1 compliant, you still wouldn't be able to do much with it.

I agree with you that it's a big problem for Tegra 4 that it is rather lacking in API compliance.  That's why I started this thread.  But given the choice between getting a new Tegra 3 system or a new Tegra 4 system, the latter is an easy call.  For that matter, given the choice between a Tegra 4 or any ARM-based chips that were on the market a year ago, the only major reasons to choose against Tegra 4 are price, power consumption, and OS.  But that is equally true of many other chips that we'll see shortly.

For what it's worth, Nvidia may have made the decision they did because they calculated that more brute force computational power in OpenGL ES 2.0 would be worth more than less computational power in OpenGL 4.3.  Sticking with OpenGL ES 2.0 lets them use non-unified shaders.  That means they can have a bunch of pixel shaders that are much weaker than the vertex shaders or unified shaders would have to be.  I don't know if they could have done that with OpenGL ES 3.0, but the full OpenGL 3.2 or later has additional pipeline stages.

And weaker pixel shaders is exactly what they did.  Anything that computes positions needs at least 32-bit floating point accuracy.  Otherwise, you'll have a bunch of depth buffer rounding errors and get massive graphical artifacting.  Pixel shaders usually don't compute positions (as the position on the screen is already given to the shader as an input) but only the color of that particular pixel.  Your red, green, and blue color values in any texture you read in are probably only 8-bit each.  So Nvidia went with 20-bit floating point precision in their fragment shaders, and not 32-bit.

That lets them have more fragment shaders, and likely makes the card benchmark better if you only run OpenGL ES 2.0 benchmarks.  That makes me hope that sites will compare chips using benchmarks using newer APIs, and mark Tegra 4 as 0 frames per second because it wouldn't run.  But they probably won't do that.

Originally posted by ShakyMo
Dx 11.1 won't be important anytime soon. Win 8 is even less popular than win vista, its possibly microsofts biggest disaster to date.

Actually Win 8 passed Vista in popularity about a week ago. But I agree that DX 11.1 won't be important for awhile.

I've been an Nvidia fan for decades now. But the Tegra technology is not one I can recommend yet. My old quad core Tegra 3 Asus tablet gets absolutely dominated by my Google Nexus 10 and it's Exynos 5 dual core. Now after hearing about the API issue with the Tegra 4, it's kind of a no-brainer to go with a device that has a more efficient and powerful cpu architecture, something with an ARM Cortex A15 (or A7) CPU.

Originally posted by AvsRock21

Originally posted by ShakyMo
Dx 11.1 won't be important anytime soon. Win 8 is even less popular than win vista, its possibly microsofts biggest disaster to date.

 

Actually Win 8 passed Vista in popularity about a week ago. But I agree that DX 11.1 won't be important for awhile.

 

I've been an Nvidia fan for decades now. But the Tegra technology is not one I can recommend yet. My old quad core Tegra 3 Asus tablet gets absolutely dominated by my Google Nexus 10 and it's Exynos 5 dual core. Now after hearing about the API issue with the Tegra 4, it's kind of a no-brainer to go with a device that has a more efficient and powerful cpu architecture, something with an ARM Cortex A15 (or A7) CPU.

Tegra 4 uses a quad core ARM Cortex A15 CPU.  It actually has five such cores, but one of them is different and optimized for lower power consumption and will only run when not much performance is needed.

---

Originally posted by Quizzical

---

Originally posted by adam_nox Isn't directx a direct interfacing with the cpu, ie not interpreted or portable?  I thought that meant you had to build a version of directx for the architecture of the cpu.  Perhaps you can still put an api on a graphics chip to support it, but I would think that it wouldn't work with smartphone cpus.  Mind you this is based on a bunch of things I just kind of assumed from random posts and stuff.   That and the ordeal android had to go through just to get flash on it (another thing that has to directly access the cpu and therefore was not portable between architectures).

---

DirectX is a collection of a bunch of APIs.  By far the best known one is Direct3D, so people often say "DirectX" to properly mean "Direct3D", which is what I did above.

Direct3D basically gives programmers a way to tell video cards to do things.  That way, instead of making the CPU do all of the work to render a game (which would work, except that you'd likely measure frame rates in seconds (plural) per frame rather than frames per second), you can make the GPU do most of the work, while the CPU just has to do the work that isn't GPU-friendly.  OpenGL is the other graphics API with capabilities comparable to Direct3D.

---

DirectX can run on anything Microsoft wants it to. It's just a list of tools that programmers can use when writing their games. Microsoft provides a high-level toolset for commonly used functions so that each programmer/developer doesn't have to implement them itself. Since Microsoft also has access to the operating system, they can chose to use undocumented or hidden OS tricks to speed things up and provide direct access to stuff that programmers/developers wouldn't normally have access to.

It happens to be compiled for Windows x86/x64. There is also a special version compiled for PowerPC (that runs the XBox 360).

The API is basically just a list of tools and works like a magic black box. You call this function, you give it these values (parameters), and it will perform this task for you. You don't actually get access to exactly how that task is performed, just what values you need to give it in order for it to work properly.

For a piece of hardware to be called "compliant" means that it can perform some particular task natively: it has a special instruction that can do some particular task in one shot, such as draw a square, or compute a tesselation, or scale a texture. Yes, you could write the code to do all that yourself, but if it's implemented in hardware, then it's much easier: you just call that hardware function and it's done in a few cycles, rather than writing a bunch of code and having it run on the CPU and several hundred/thousand cycles.

One quick example would be multiplication:
It's easy to say:

x = 3 * 3;

... but if (for some strange reason) your hardware didn't have a "Multiply" function, you would have to perform that in software

x = 0;
i = 0;
for i < 3
{
    x = x + 3;
    i = i + 1;
}

With hardware support - boom, you have your answer in one stroke. With software support, it takes several iterations and a lot more complication to arrive at the same answer. Imaging doing that with 3D spaces computing hundreds upon thousands of vectors: with hardware support: boom, your done with one call. Trying to do that with software quickly bogs down. That's what being DX/OGL Compliant means.

Intel actually used to call some of their early graphics chips "compliant" but they performed a lot of the functions in software at the driver level, so the OS couldn't tell that they weren't performed in hardware (and they may do so still). They had a lot of issues with those early chipsets, and were extremely slow.

Originally posted by Ridelynn

For a piece of hardware to be called "compliant" means that it can perform some particular task natively: it has a special instruction that can do some particular task in one shot, such as draw a square, or compute a tesselation, or scale a texture. Yes, you could write the code to do all that yourself, but if it's implemented in hardware, then it's much easier: you just call that hardware function and it's done in a few cycles, rather than writing a bunch of code and having it run on the CPU and several hundred/thousand cycles.

Now that I stop to think about it, it's actually very complicated to say what it means for hardware to be OpenGL compliant.

I haven't dealt with DirectX, but with OpenGL, it's basically a matter of, if you use these particular functions, the video card has to give this particular behavior.  It does not say how fast it has to run, but it does have to do it without additionally consulting the processor.  Or at least I think it does.  For example, OpenGL 4 requires hardware to be able to do 64-bit floating point computations, but doesn't say it has to do them fast, so most OpenGL 4 compliant video cards do 64-bit computations at 1/24 to 1/16 of the speed of 32-bit computations.

In some cases, it specifies the behavior exactly:  every bit of an 11-bit unsigned floating-point number has to have exactly this meaning.  In some cases, it only says you have to come kind of close:  if you draw a line from this point to that point, the ideal behavior would be such and such, but anything that isn't shifted from ideal by more than 1 pixel is acceptable.  In some cases, it even says the hardware can give whatever value it wants, such as if a user tries to cast a negative floating-point number to an unsigned integer in GLSL.  That's basically a warning to programmers of "don't do this!" in many cases, or at least don't rely on different invocations of the shader being executed in some particular order.

But where it really gets weird is shaders.  You pass a string to the video drivers, and it treats it as source code and compiles it into a binary executable that can run on that particular video card.  No, really, it's a string, kind of like an array of characters.  And the drivers have to stop to compile it while the game is running (this will typically be done when you launch the game, though changing certain graphical settings could also trigger it), and then the compiled program has to give particular behavior.

Originally posted by Gravarg
I think the problem ME had was that 2000 was so good and prevailant, people just skipped over ME.

I'm sure the huge memory leak had nothing to do with it.

---

Originally posted by birdycephon

---

Originally posted by Gravarg I think the problem ME had was that 2000 was so good and prevailant, people just skipped over ME.

---

I'm sure the huge memory leak had nothing to do with it.

---

Well, it could also be that 98 was relased in June of 98, ME was released in Sept of 2000, while Windows 2000 was released in Feb of 2000. And XP was released in Aug of 2001.

So there was only a short window (11 months) for it to really catch on, and there was a viable alternative (Win2000) that didn't have all these negative perceptions. Anyone doing anything serious went to Win2000, and most home users didn't see the need to upgrade past 98 (it worked fairly well for it's time). The few people that got ME complained loudly (like they did with Vista, and are doing with 8), so the people without it just stayed away, and it never hit critical mass.

Originally posted by Gravarg
I think the problem ME had was that 2000 was so good and prevailant, people just skipped over ME.

Of course not everyone with ME had problems, but I assure you, a LOT of people did.  A lot more than any other operating system.  I worked on people's computers back then, it was sometimes very very awful.

Opengl is just an api. Its up to the hardware devs to make openl stuff run. So tesselation in nvidia could be implemented in hardware differently from amd. This is not the case in d3d where microsoft controls how everything is implemented even down to the hardware level. So a dx9.0c compliant card will be exactly the same in nvidia and amd graphics card.

Tldr:
Opengl only enforces the api(function names n high level descriptions).
Dx enforces the api and how its implemented in hardware and software.

Edit :

Shaders have completely seperate compliance-ness from the actual graphics api. 

Originally posted by Castillle
Opengl is just an api. Its up to the hardware devs to make openl stuff run. So tesselation in nvidia could be implemented in hardware differently from amd. This is not the case in d3d where microsoft controls how everything is implemented even down to the hardware level. So a dx9.0c compliant card will be exactly the same in nvidia and amd graphics card.

Tldr:
Opengl only enforces the api(function names n stuff)
Dx enforces the api and how its implemented in hardware and software.

I don't see how Microsoft even could do that, as GPU designers have to have considerable freedom on how to implement things in order to optimize performance.  No video card is going to have dedicated hardware to multiply two 4x4 matrices of 32-bit floating point numbers that is completely separate from the hardware they use to multiply a 4x4 matrix from a 4x3 matrix of 32-bit floating point numbers.  Rather, the drivers would interpret it as a bunch of vectorized FMA and multiplication operations.