Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 72 of 173 FirstFirst ... 2262707172737482122172 ... LastLast
Results 711 to 720 of 1724

Thread: OpenGL 3 Updates

  1. #711
    Junior Member Regular Contributor
    Join Date
    Aug 2007
    Location
    USA
    Posts
    243

    Re: OpenGL 3 Updates

    I have to agree with Korval here... and plus, there are still things on a graphics card that simply aren't generalized (such as texture-related hardware).

  2. #712
    Member Regular Contributor
    Join Date
    Mar 2007
    Location
    California
    Posts
    396

    Re: OpenGL 3 Updates

    GL3 is a API cleanup and some small amount of performance and consistency. It won't make PC gaming better.
    One of PC gaming's biggest problems is bad drivers. Do you think it is in Microsoft or Epic's best interests that PCs have reliable drivers, when they are so heavily invested in obsolete console technology? I am not saying they are responsible, but I am saying there are large companies that should see OpenGL3 as a minor threat, or at least not something that they are going to benefit from. And I would not put it past any of those companies to drag their feet on coming to an agreement about some bit of IP they hold.

    I think that is the best guess possible of what has happened. We all know it is an IP issue, or they would have provided some explanation. And there are motivations for companies involved to not fully cooperate with Khronos. I don't know if this is coming from Microsoft, Sony themselves, or someone else, but it looks to me like someone has sicked their lawyers on Khronos at the last possible moment.

  3. #713
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Quote Originally Posted by Jan
    On the other hand, what i heard about Sony, they are still more of a hardware-company and their tools are supposed to be quite limited (more information from people who know what they are talking about is much appreciated!), so maybe they just don't care much and think it is the developers problem, not theirs.
    I work for a company which does games for various platforms, right now I'm working on an eyetoy game for the PS2. The tools we have for that are not what you'd call top of the line.

    The compile is GCC, which is probably the best bit about it; the IDE is Codewarrior, known through the land by people who have to deal with it as 'the biggest pile of crap every to be called an IDE' (see below for an example).

    I understand things aren't much better in PS3 land either, I dare say if I move to a PS3 project when this one is done I'll find out.

    On the plus side you do get very detailed docs from them, both in paper and pdf format which cover basically everything about how the chips work. Although, I'd perfer better tools

    ---
    So, it's thursday evening, about 5pm and I wander over to a co-worker desk to kill some time as I was feeling lazy that day. I find him looking puzzled at some spotlight code in the engine which didn't seem to work. The main issue he had was, when tracing into a function with an asm block in it the correct result never seemed to be returned. I was surprised by this as it was the dotproduct() function, one which is used all over the place and you'd have thought it would have been noticed before now.

    So, he runs the program, we trace into it and low and behold the debugger says that our return variable is never written to and as such the returned value is rubbish. Due to the time he was going home so we deffered it to our lead to sort out the next day.

    Next day I wander if at 10am (yay flexible hours) and at about 10:30am notice our lead was in but hadn't been to his desk. So, I was to my co-workers desk from last night (which is in a side room) to find him and my lead, PS2 manuals out, trying to find out wtf is going on with this function.

    Long story short I cracked in the end as I had slightly more knowledge of assembly than the others looking at it (at one point there we 4 programmers staring at this problem); once I looked back at the call site I realised that what was happening was the value was being left in a register in the function call and then used directly afterwards which is why the memory location wasn't updated.

    This was confusing becasue looking at the assembly generated the compiler reserves space on the stack for the variable to be returned, sets it to zero as asked and then at the end cleans it up without ever using it.

    In release mode, fine, but this was debug mode. Sometimes the debugger can track things in registers but this time it wasn't playing ball either.

    It was around midday I finally cracked this, after learning how PS2 assembly works, the calling convention and refreshing my mind about the gcc asm command; thats 1h 30mins of my time and around 2h of my lead and co-workers time gone because either the debugger didn't do things right or the compiler was being too smart.

  4. #714
    Senior Member OpenGL Pro Zengar's Avatar
    Join Date
    Sep 2001
    Location
    Germany
    Posts
    1,932

    Re: OpenGL 3 Updates

    Quote Originally Posted by Korval
    is there really a point in a new graphics API?
    Yes. Because no matter how general-purpose a GPU becomes, it's still a GPU. And the most effective way to set that GPU up is not something that a graphics programmer should have to know.
    I disagree. A GPU that just includes multiple processing units with no specialized hardware for graphics-related tasks (excluding maybe a dedicated texturing hardware) is not a GPU in the common sense anymore, and I would expect such cards to appear in next generations (ATI cards do not even have dedicated multisampling hardware anymore, and if I am not mistaken G80 does rasterization via it's shader units). Of course it puts more strain on the graphics programmer to do "everything by himself", but I expect some open-source frameworks that take over most usual tasks (like rasterization) to emerge soon after stream processing hardware becomes common (much like programming libraries).
    Also, it gives you the power to use the hardware in the most beneficial way possible for your application, which will soon result in new interesting techniques and methods.

    GP-GPU APIs and the like are not good graphics APIs.
    True, but it boils down to "what is actually there". This way, a graphics API would be just a layer on the top of the stream processing API.

  5. #715
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Right, so you accept there has to be a level above a stream processing API for graphics to work, so what better group to write that level than the people who know how the gfx card works?

    And at that point why bother putting it above it? Why not just have the two APIs to avoid the call over head?

    And tada! OpenGL or D3D is still needed.

    Personally, I'd much rather the guys who knew about the hardware dealt with all that stuff and let me get on with telling it where I want my stuff to be drawn. I don't want to have care about these things. It's bad enough as it is, now imagine having to trawel through code to setup everything just how you need it.

    The whole 'oh, someone will write a framework for it' might be great for people just playing about, but once you get out of the GLUT like sandbox world and need more control you need to start digging.

    And no two pieces of hardware will be made equal. The way to treat AMD will differ from NV will differ from Intel and it's bad enough right now; imagine having to effectively do what drivers do now for bits of hardware when new stuff comes out?

    *shudders*
    No, a GP-GPU API is all well and good for GP-GPU apps but for a specific problem domain, such as 3D graphics, a dedicated API and driver is to be prefered.

  6. #716
    Junior Member Regular Contributor
    Join Date
    Apr 2001
    Posts
    180

    Re: OpenGL 3 Updates

    Yeah you can code for the x86 cpu using ASM, or you can just use one of the highly optimizing C++ compilers... I'm guessing the same will be true for whatever comes next on the graphics front.

  7. #717
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: OpenGL 3 Updates

    Quote Originally Posted by bobvodka
    OpenGL or D3D is still needed.
    Though I think the difference is that those future APIs could be written by anyone; sitting on top of some lower level plumbing they'd be more like GLU or D3DX, requiring little or no driver internals and such... just a specialized convenience layer atop a much more general infrastructure.

  8. #718
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,575

    Re: OpenGL 3 Updates

    Do you think it is in Microsoft or Epic's best interests that PCs have reliable drivers, when they are so heavily invested in obsolete console technology?
    For Epic? Absolutely.

    Shocking though it may be to believe, console games are developed on PCs. They use 3D tools like Max, Maya, or XSI. Some even have an in-house PC port that they use for early development (so as not to require the more optimized asset conversion process for console builds). Those tools need reliable drivers in order to function. Artists need to be able to develop shaders and see them work in those tools, so that they don't have to go through a lengthy export and asset conversion process just to see if their mesh works correctly.

    For Microsoft? Even moreso.

    Vista (and every post-Vista OS) is built on video drivers. Every graphical element, whether AeroGlass or not, goes through Direct3D and 3D graphics card drivers. If those don't work, the OS fails. Period.

    And that's not something Microsoft wants.

    Do Epic and Microsoft need OpenGL drivers in particular? No. But Epic, and any other non-Microsoft PC developer, would be entirely neutral on OpenGL 3.0.

    Lastly, an aside: console technology is not "obsolete". If you're a PC gamer filled with bitterness at seeing so many companies abandon your platform for consoles, you have my pity. But keep the bile off this forum.

    And I would not put it past any of those companies to drag their feet on coming to an agreement about some bit of IP they hold.
    And yet, none of these companies are in a position to hold up GL 3.0's development. Microsoft long since quit the ARB. And Epic has never had any pull with them.

    I'm working on an eyetoy game for the PS2.
    You have my sympathy.

    the IDE is Codewarrior, known through the land by people who have to deal with it as 'the biggest pile of crap every to be called an IDE' (see below for an example).
    That's strange; PS2 doesn't have an IDE. If you're using Codewarrior, that's because that is what your company provided you with. I used Visual Studio (through a makefile-based project) just fine with PS2. Debugging was handled via an external application that was certainly not Codewarrior.

    A GPU that just includes multiple processing units with no specialized hardware for graphics-related tasks (excluding maybe a dedicated texturing hardware) is not a GPU in the common sense anymore
    I would also add that a GPU that doesn't include any specialized hardware for graphics-related tasks is not a good GPU. So it's fairly irrelevant to talk about such things. It's more like something pretending to be a GPU.

    Though I think the difference is that those future APIs could be written by anyone; sitting on top of some lower level plumbing they'd be more like GLU or D3DX, requiring little or no driver internals and such...
    But because low-level interfaces are so, well, low-level, you will need intimate knowledge of how the hardware works to write a higher-level interface that properly abstracts the hardware without losing performance. Hence: OpenGL. "Anyone" will not be writing such implementations; they should be written by people with actual deep hardware knowledge.

  9. #719
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: OpenGL 3 Updates

    Quote Originally Posted by Zengar
    I don't know if this thought was already expressed by anyone, but is there really a point in a new graphics API?
    if you take a close look at cude, there is not much that sets it appart from todays shaders (my personal opinion). extend the shaders to access shared resources (shared on chip memory) and scatter writes and you have all you need plus all as graphics api gets you.

    trying to implement ray tracing using cuda is cool but at some point you begin to build stuff you have with opengl (like normal bindable textures or texture arrays...). i think an small extension to the cross platform shader apis brings much of the cuda capabilities. (because _we_ want to do graphics with it)

  10. #720
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3 Updates

    I agree with bobvodka and Korval:

    Even if it were possible to write a graphics API on top of some stream API, such that non IHVs could make it, where's the point?!

    First of all, such a group would need to sell it's API, to make a living, instead of giving it away for free, as it is now. That is, because if it were an open source project (ie. a hobby-project) it would be too unreliable. You know, some GPUs get well supported, because the project-lead has that GPU on his computer, sometimes there are many updates, sometimes there are none for a long time...

    It wouldn't work well, unless it is a dedicated company.

    On the other hand, no matter how general purpose GPUs become, the fact is, that they will always be mainly used for graphics, because people buy them as graphics cards! So, even if GPUs will compete as GPGPUs in the future, they will still also compete as plain graphics cards. And that is why IHVs will keep being interested in having good graphics drivers. Most software developers are not able to write a rasterization renderer today. I couldn't. And this is A GOOD THING. Not the missing knowledge itself, but the fact that we don't need to.

    What my biggest problem is with the discussion about "not needing graphics APIs in the future anymore" is, that it neglects the development in the software industry of the last 15 years (at least). Software is becoming so complex and so huge, it is not possible to write the whole code of a game in a few years, anymore. It's not like it was with Quake. All these great games today are only possible, because of heap loads of middleware, INCLUDING a graphics API. It is complicated enough writing a great renderer, no one wants to be forced to also write the low-level stuff. Especially not for different types of GPUs.

    Of course i agree, that it is nice to be ABLE to write your own graphics stuff using a stream API. Just as it is nice to use assembler to interface more directly with your CPU. But only because you will be able to do it, should not mean that you should need to do it (or rely on some other non IHV company to do it for you).

    Jan.
    GLIM - Immediate Mode Emulation for GL3

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •