the amount of extra money nintendo spend on eDRAM would've been better spent on more system RAM
Sony Prove the Wii U's Texture Bandwidth is not slow
#21
Posted 15 July 2013 - 01:04 PM
#22
Posted 15 July 2013 - 01:08 PM
the amount of extra money nintendo spend on eDRAM would've been better spent on more system RAM
More RAM does nit equal better graphics. Grab a Pentium III, a X1800 Radeon GPU and 32GB of RAM (yes, I know that system can't use that amount of RAM) ... It isn't more powerful then my PC with an AMD A8 APU and 16GB or RAM. Nor is it more powerful than the Wii U.
So no, it would have been a poor choice to make the system less powerful just so you can have more RAM.
#23
Posted 15 July 2013 - 01:12 PM
More RAM does nit equal better graphics. Grab a Pentium III, a X1800 Radeon GPU and 32GB of RAM (yes, I know that system can't use that amount of RAM) ... It isn't more powerful then my PC with an AMD A8 APU and 16GB or RAM. Nor is it more powerful than the Wii U.
So no, it would have been a poor choice to make the system less powerful just so you can have more RAM.
I'll add to this by also saying to the poster Morbid is quoting:
Um, no. Nintendo knew what they were doing here. Say what you want to about how weak the Wii U is, but without the eDRAM, we'd have a much worse system. 4GB RAM instead of 2GB would hardly make up for it.
#24
Posted 15 July 2013 - 01:38 PM
I'll add to this by also saying to the poster Morbid is quoting:
Um, no. Nintendo knew what they were doing here. Say what you want to about how weak the Wii U is, but without the eDRAM, we'd have a much worse system. 4GB RAM instead of 2GB would hardly make up for it.
if nobody is using the eDRAM whats the point in having it.
#25
Posted 15 July 2013 - 01:53 PM
if nobody is using the eDRAM whats the point in having it.
I think every game technically uses it. However, some games could take better advantage of it than others.
#26
Posted 15 July 2013 - 03:37 PM
if nobody is using the eDRAM whats the point in having it.
The same could be said about all that RAM PS4 and X1 has. Of no one is using it, why have it?
#27
Posted 15 July 2013 - 09:38 PM
Developers could be confusing GPU performance with improper use of the edram. GPU performance cannot be maximized without proper use of the edram, without using it properly the GPU will not be able to run at its maximum potential. Its up to the developer to make sure they are getting the most bang for their buck with the edram. From what I can gather, this means that the frame buffers/Z buffer would stay in the edram saving tons of bandwidth. However, this only leaves about 12-16MB for textures. So the majority of textures would still need to come from the main memory pool.
Right, and even though honestly disc streaming along with the main ram bandwidth is enough for most applications (textures aren't as bandwidth hungry as some would think) prioritizing commonly used textures to be housed in EDRAM would be effective, but it depends on the game being developed.
if nobody is using the eDRAM whats the point in having it.
They aren't using the EDRAM 'yet'. Many of them simply hadn't figured out what they were doing with the system, and Nintendo's tools weren't very good (you could argue even Nintendo didn't really know what they were doing with the system yet) when the current crop of games was released. Obviously there are a couple that use it lightly, like Shin'en's game and Trine 2. Just goes to show you that the indie guys were able to get more acquainted with the system in a shorter period of time than big house publishers. A testament to their engineering prowess.
- Dragon and NintendoReport like this
#28
Posted 15 July 2013 - 09:52 PM
i really feel seriously Nintendo needs to(now that they have updated tools) hold abasic development class for Wii U. because its seems developers are dumbfounded when it comes to developing for this console. Im not a developer and never ahd developed for a HD console but can it be this hard? they seem like they have no idea how to make games run properly on this console.
- BlueBlur likes this
#29
Posted 16 July 2013 - 06:00 AM
Right, and even though honestly disc streaming along with the main ram bandwidth is enough for most applications (textures aren't as bandwidth hungry as some would think) prioritizing commonly used textures to be housed in EDRAM would be effective, but it depends on the game being developed.
They aren't using the EDRAM 'yet'. Many of them simply hadn't figured out what they were doing with the system, and Nintendo's tools weren't very good (you could argue even Nintendo didn't really know what they were doing with the system yet) when the current crop of games was released. Obviously there are a couple that use it lightly, like Shin'en's game and Trine 2. Just goes to show you that the indie guys were able to get more acquainted with the system in a shorter period of time than big house publishers. A testament to their engineering prowess.
Considering that most developers have let themselves become factory production lines I get the feeling they don't really WANT to learn architecture more complex than "let's just keep throwing a bunch of RAM at it!" AAA production has just become such a mess that even the SLIGHTEST deviation throws wrenches in their beloved plans. It's kind of sad
- Goodtwin likes this
#30
Posted 16 July 2013 - 06:15 AM
Considering that most developers have let themselves become factory production lines I get the feeling they don't really WANT to learn architecture more complex than "let's just keep throwing a bunch of RAM at it!" AAA production has just become such a mess that even the SLIGHTEST deviation throws wrenches in their beloved plans. It's kind of sad
Quite true. The beauty of the RAM limitations for the PS3 and 360 (it was limited even for 2006) was that it forced them to work harder to actually improve the visuals over time, and they have done a wonderful job with it over the years. Of course devs are always going to want more RAM. That will never change. Whether they are willing to learn to develop for a particular platform in the end comes down to whether they believe that they can make money on that platform. Wii U can do anything the other consoles can do for the most part, its just a matter of how much effort developers are going to put into extracting that performance. The good thing is that its actually the PS4 that is the odd man out. That's the platform where I think developers will get a little lazy with their memory management. XB1 is architecturally more similar to Wii U, just with a larger main RAM pool, which in the end isn't going to be the limiting factor for any of the consoles. Dev talk is swirling that XB1 performs more like Wii U as well.
Using anecdotal evidence from developers who have released games on the platforms, we have a system that is really easy to develop for, but a little more difficult to completely optimize.
#31
Posted 16 July 2013 - 06:23 AM
#32
Posted 16 July 2013 - 06:56 AM
eDRAm is dynamic, which mean it needs to be constantly refreshed, while eSRAM is static, it means it doesn't. This is great news btw: http://nintendoevery...rd-easy-to-use/
“Wii U GPU and its API are straightforward”, adding how it possesses “plenty of high bandwidth memory” and is “easy” -- via Shin'en Multimedia's Twitter Account
Edited by Arkhandar, 16 July 2013 - 06:59 AM.
#33
Posted 16 July 2013 - 07:43 AM
Quite true. The beauty of the RAM limitations for the PS3 and 360 (it was limited even for 2006) was that it forced them to work harder to actually improve the visuals over time, and they have done a wonderful job with it over the years. Of course devs are always going to want more RAM. That will never change. Whether they are willing to learn to develop for a particular platform in the end comes down to whether they believe that they can make money on that platform. Wii U can do anything the other consoles can do for the most part, its just a matter of how much effort developers are going to put into extracting that performance. The good thing is that its actually the PS4 that is the odd man out. That's the platform where I think developers will get a little lazy with their memory management. XB1 is architecturally more similar to Wii U, just with a larger main RAM pool, which in the end isn't going to be the limiting factor for any of the consoles. Dev talk is swirling that XB1 performs more like Wii U as well.
Using anecdotal evidence from developers who have released games on the platforms, we have a system that is really easy to develop for, but a little more difficult to completely optimize.
Which is what devs HATE nowadays; they hate having to actually put EFFORT into making something work. They want to able to just push a button and have everything be perfect. This is what happens when you let game development become prohibitively expensive. If it has gotten to the point where doing a simple port is too much work, then that is a problem with YOU, not the system. This is why indie devs have had absolutely no trouble with the system while big names whine and moan CONSTANTLY.
#34
Posted 16 July 2013 - 08:37 AM
I personally can't wait to see Shin'ens next game for the Wii U, those five guys know what they're doing.
#35
Posted 16 July 2013 - 09:37 AM
Right, and even though honestly disc streaming along with the main ram bandwidth is enough for most applications (textures aren't as bandwidth hungry as some would think) prioritizing commonly used textures to be housed in EDRAM would be effective, but it depends on the game being developed.
They aren't using the EDRAM 'yet'. Many of them simply hadn't figured out what they were doing with the system, and Nintendo's tools weren't very good (you could argue even Nintendo didn't really know what they were doing with the system yet) when the current crop of games was released. Obviously there are a couple that use it lightly, like Shin'en's game and Trine 2. Just goes to show you that the indie guys were able to get more acquainted with the system in a shorter period of time than big house publishers. A testament to their engineering prowess.
What was the point in Nintendo making it so hard for developers to code for then ?
#36
Posted 16 July 2013 - 05:44 PM
What was the point in Nintendo making it so hard for developers to code for then ?
They dont. Nintendo simply just doesnt cater to incompetent port teams only capable of working with high level middlware.
Its like some kid who thinks hes a god tier programmer becauase he can make a game with rpg maker, and then saying c++ sucks and is weak when he cant do anything worthwhile.
Nintendo makes hardware first and foremost for THEIR PROGRAMMER, who are among the oldest and most experienced anywhere in the industry. The things other developers are getting hung up on is just common practice to them.
They chose price and performance over convenience in their design, which is why they have things like a sophisticated memory heiarchy, and left time slicing under dev control.
Thats why nintendo can make stuff that looks like this: (sorry about the res, its a miiverse capture)
With the wii u, while port team hacks cant even get their garbage looking ports running well.
Its also why older devs used to making their own engines arent having any trouble with wii u.
#37
Posted 16 July 2013 - 05:49 PM
They dont. Nintendo simply just doesnt cater to incompetent port teams only capable of working with high level middlware.
Its like some kid who thinks hes a god tier programmer becauase he can make a game with rpg maker, and then saying c++ sucks and is weak when he cant do anything worthwhile.
Nintendo makes hardware first and foremost for THEIR PROGRAMMER, who are among the oldest and most experienced anywhere in the industry. The things other developers are getting hung up on is just common practice to them.
They chose price and performance over convenience in their design, which is why they have things like a sophisticated memory heiarchy, and left time slicing under dev control.
Thats why nintendo can make stuff that looks like this: (sorry about the res, its a miiverse capture)
With the wii u, while port team hacks cant even get their garbage looking ports running well.
Its also why older devs used to making their own engines arent having any trouble with wii u.
That is an impressive miiverse capture.
PA Magician | Busiest PA Magician | Magician Reviewed | Certified Magic Professionals
-- --
#38
Posted 17 July 2013 - 12:39 AM
AWESOME NEWS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I think.......................
#39
Posted 17 July 2013 - 06:11 AM
What was the point in Nintendo making it so hard for developers to code for then ?
It isn't which is the point I was making. It's actually very easy to code for, but a little harder to completely optimize (considering its the platform with the most divergent architecture and the most custom logic, and actually incorporates bold new hardware direction) whereas you'll see more out of the other platforms earlier on but it will more than likely stagnate, because more RAM can only take you to a point where you have a beautifully detailed slideshow presentation, it doesn't actually help performance at all. The GPU performance difference for what we know of the Wii U GPU logic and the PS4's advertised specification aren't spread enough to make a big difference performance wise, especially considering they can both technically do all of the same things, however Nintendo has added custom logic to make certain things more efficient (we can speculate about what it is, but I think this makes sense as is).
They dont. Nintendo simply just doesnt cater to incompetent port teams only capable of working with high level middlware.
Its like some kid who thinks hes a god tier programmer becauase he can make a game with rpg maker, and then saying c++ sucks and is weak when he cant do anything worthwhile.
Nintendo makes hardware first and foremost for THEIR PROGRAMMER, who are among the oldest and most experienced anywhere in the industry. The things other developers are getting hung up on is just common practice to them.
They chose price and performance over convenience in their design, which is why they have things like a sophisticated memory heiarchy, and left time slicing under dev control.
Thats why nintendo can make stuff that looks like this: (sorry about the res, its a miiverse capture)
With the wii u, while port team hacks cant even get their garbage looking ports running well.
Its also why older devs used to making their own engines arent having any trouble with wii u.
Considering that Pikmin 3 started its life as a Wii game (and many of the assets in the game are probably hold overs) this is fantastic. I've seen people complaining about textures when all they are looking at is the ground cover (grass) texture when in Koppaian eye level mode (gamepad cam), which those textures weren't optimized for. They were optimized for the overhead perspective, and adding ground cover geometry would only make it harder to manage your army of alien slaves.
#40
Posted 17 July 2013 - 06:38 AM
It isn't which is the point I was making. It's actually very easy to code for, but a little harder to completely optimize (considering its the platform with the most divergent architecture and the most custom logic, and actually incorporates bold new hardware direction) whereas you'll see more out of the other platforms earlier on but it will more than likely stagnate, because more RAM can only take you to a point where you have a beautifully detailed slideshow presentation, it doesn't actually help performance at all. The GPU performance difference for what we know of the Wii U GPU logic and the PS4's advertised specification aren't spread enough to make a big difference performance wise, especially considering they can both technically do all of the same things, however Nintendo has added custom logic to make certain things more efficient (we can speculate about what it is, but I think this makes sense as is).
Considering that Pikmin 3 started its life as a Wii game (and many of the assets in the game are probably hold overs) this is fantastic. I've seen people complaining about textures when all they are looking at is the ground cover (grass) texture when in Koppaian eye level mode (gamepad cam), which those textures weren't optimized for. They were optimized for the overhead perspective, and adding ground cover geometry would only make it harder to manage your army of alien slaves.
Its not just that they werent optimized for eye level mode, but that eye level mode is less than an inch off the ground, there really isnt much practical you can do about the anisotropy at that point.
ainisotropic filtering does wonders at 6 feet, or even for crouching at say 3 feet... but an inch off the texture at that oblique angle? Thats a tough situation.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users