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 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: win10 trouble

  1. #1
    Intern Contributor
    Join Date
    Jul 2013
    Posts
    96

    win10 trouble

    yow all

    A 'new' refurbed ultrabook using win 10 pro and with updated graphics-driver that matches opengl 4.4 cannot execute my previous opengl works done within a forward compatible 3.3 profile on win 7. ?
    It does not show errors except for a very general draw-call error .. it executes the program and my cout debug info, but shows nothing on screen.

    I will not ask Microsoft since it's their best interest to see openGL in error and that I at best will get the merry-go-round there.

    Has anyone got a clue?

    edit: an odity: I tested the graphics-card and it had a fps +900 .. that should be plenty for a 60hz screen..

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,546
    Quote Originally Posted by CarstenT View Post
    Has anyone got a clue?
    You might provide more details. There's not much here to latch onto.

    For instance, you haven't told us:

    • what GPU and graphics driver you had installed on there before,
    • what GPU and graphics driver you have installed now (try running GPU-Z or GL Caps Viewer), and
    • what the error is.

    You have told us that your program(s) were/are targeting a "forward compatible 3.3 profile". Why? Was your old box running Mac OS? Try removing the forward compatibility bit.

  3. #3
    Intern Contributor
    Join Date
    Jul 2013
    Posts
    96
    hi Photon
    I cannot right-away provide what you ask (have to leave home to the net on local library), but I'll try from my head:
    The pc that created the programs is pretty old and has a minor gforce graphics card that provides a 3.3 openGL version. The programs are worked upon till some degree of perfection (meaning that they execute without problems here). The pc runs win7 pro.
    The problems appear on my /new/ and modern ultrabook running on win10 pro using an intel family cpu (somewhere displaying number 5300). The gpu is shared with the cpu. This pc is new to me, and I'm catching up slowly on it's peculiarities. I've only tried to load one program (a game) and it's failed too .. I can get a proper display or a fair sound (each belonging to it's own compabillity-choise), but not both.

    As for a host of my own opengl works saved over time, they seems to have one thing in common: they display nothing on the screen except perhaps the first line: gl_clear_color(some_color) . I've run the extensions-viewer and it finds support up to and including ver 4.4.
    Most of my works shares the same initiation. It's put into a try/if and ought to break out of the program. I've just looked at the error-code from some of my latest work, and it does show, that there seems to be errors in the shaders. Since I have not yet come to building the tool-chain on the pc I have only gleaned shortly at the code .. it does not make much sense (referring to 'FragUserData' and 'aTexture' .. not variables that I can recognise). The try/if rescue code for breaking out of the program may be faulty .. I've not used it very much, but it does not close down the programs as I would expect.
    Anyway, this shader-stuff is an error-path for me to follow.
    But .. I find it strongly suspect that ALL my stuff (and prof programs) all that works well everywhere else, fails.

    The bare idea of trying to set up the tool-chain for working on THAT pc makes me feel as if I got chicken-pox, but that was the general idea for buying it.

    Thanks for your input DP

    ...
    doesn't forward-compatible mean that my code will be rock-solid once it meets future gpu's ? ... as is what is exactly happening? I might not be the brightest tree in the wood, what else should it mean?
    Last edited by CarstenT; 09-07-2018 at 11:30 AM.

  4. #4
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,546
    Quote Originally Posted by CarstenT View Post
    The problems appear on my /new/ and modern ultrabook running on win10 pro using an intel family cpu (somewhere displaying number 5300).
    As for a host of my own opengl works saved over time, they seems to have one thing in common:
    they display nothing on the screen except perhaps the first line: gl_clear_color(some_color) .
    I've run the extensions-viewer and it finds support up to and including ver 4.4. ...

    there seems to be errors in the shaders. ...
    it does not make much sense (referring to 'FragUserData' and 'aTexture' .. not variables that I can recognise).
    Ok, so you're switching from an old NVidia GeForce GPU to an Intel HD Graphics 5300 GPU embedded in your CPU which has OpenGL 4.4 drivers installed (though we're not sure whether that's OpenGL 4.4 Core Profile, or OpenGL 4.4 Compatibility Profile).

    Doing a quick websearch for the shader error fragments you mentioned, I see:



    The common thread being folks running on their embedded Intel GPU with Intel drivers seem to have this problem, but when they flip to an NVidia GPU with NVidia drivers the problem goes away.

    A piece of the error messages listed gives a clue:

    Code :
    WARNING: 0:52: 'texture2D' : function is deprecated and not available in Core Profile context
    or
    Code :
    ERROR: 0:15: 'texture2D' : function is removed in Forward Compatibile context

    So, it may be that you are (as you indicated) creating a forward-compatible or core context, and your shaders are using deprecated or removed OpenGL features. That seems like the best bet. Alternatively, it could be that your shaders are buggy, the drivers don't support the compatibility profile very well, or the driver may have a bug.

    If you want the widest OpenGL feature support possible, create a GL context with the "compatibility profile". NVidia and AMD have wide support for this across all OpenGL versions. Other vendors have more limited support. You should check into your Intel's GL drivers and determine the maximum "core profile" version your drivers support as well as the maximum "compatibility profile" version they support, and write your code accordingly.

    doesn't forward-compatible mean that my code will be rock-solid once it meets future gpu's ? ... what else should it mean?
    I can see that interpretation. But what it actually gives you is the maximum number of "old OpenGL features" disabled. The idea is that if you accidentally use a feature deprecated in some OpenGL version, it might be removed in a future version. So "forward compatible" doesn't even let you get started using it when you are writing the code. It makes it completely unavailable.

    For more on Forward-compatibile Contexts, see this link: OpenGL_Context#Forward_compatibility
    Last edited by Dark Photon; 09-08-2018 at 03:37 PM.

  5. #5
    Intern Contributor
    Join Date
    Jul 2013
    Posts
    96
    Hi DP,

    "Ok, so you're switching from an old NVidia GeForce GPU to an Intel HD Graphics 5300 GPU embedded in your CPU which has OpenGL 4.4 drivers installed (though we're not sure whether that's OpenGL 4.4 Core Profile, or OpenGL 4.4 Compatibility Profile)."

    ... just to forego misunderstanding: My opengl-work has been done on the win7 pc, and the .exe's are attempted executed on the win10 pc .. which fauls everything up. The execution shows no errors on the win7. The extensions-viewer says ver 4.4 for the win10 pc, and 3.3 for the win7 pc.

    I had a quick attempt on the source-code in win7, to change the compiled version from 3.3 to 3.1 or 3.0 and the debugger pointed to a few functions that was used and not supported (one of which was somewhere in the uniform-location process) .. the cascade of changes needed held me from going any further.

    I should have a look at the textureD2 stuff .. it could make sense as a single source for some of the errors.

    Both the pc-type (ultrabook, Lenovo thinkpad) and win10 are new to me, so I'm faced with a lot of changes from my usual pc-rutines. I havn't installed the win10, and those who did may not have installed any update of Lenovos - I'm investigating this side of the possibilities right now. It would make sense that all problems are fixed here.

    I've copied your reply for closer scrutiny.

    I'll pop by and tell you the progress,
    thanks & Cheers

  6. #6
    Intern Contributor
    Join Date
    Jul 2013
    Posts
    96
    hi again
    For now, my 'new' pc is a lost case.
    I just checked the graphics driver for that pc online (it provides no opengl info on it's own). The driver loaded should support opengl 4.x. You'll probably know the bewildering status of previous win-versions: you would have to update the driver yourself, to get the opengl functionality. I shall assume that the driver-part is ok. That leaves the principiel question:
    If I build an executable on win7 of an opengl 3.3, forward compatible, core profile it should be executable on win10 opengl 4.x. Right?
    If I got it wrong, which profile should I build it on win7 then, if I want to avoid the full shebang?

  7. #7
    Intern Contributor
    Join Date
    Jul 2013
    Posts
    96
    Hi,
    I've been tempted to start a new thread on this, but it's no good etikette ..
    To recap: I've build a program (on toolchain on win7 mashine (opengl ver 3.3) ) that does run flawless, but not on another laptop win10 (opengl ver 4.4). I'll skip further info here since the error-info I get from the win10 mashine sort of 'cries to the skies':

    It's building the fragmentshader that fails.
    The program contains two program objects with each their shaders.
    The first build is no more complex than setting the the fragment-color:


    fragment_shader_string=
    "#version 330 core \n"
    "precision highp int;\n"
    "precision highp float;\n"
    "flat in vec4 coll;\n"
    "flat out vec4 FragColor;\n"
    "void main(){ \n"
    " FragColor = coll ;\n"
    "}\n";


    the error it spawns is at line 5: flat out vec4 FragColor;
    Oddly enough the short error refers to 'FragUserData' (..cannot be interpolated') and not the name of the variable.


    The other program-object is more complicated since it involves a texture:
    fragment_shader_string=
    "#version 330 core \n"
    "precision highp int;\n"
    "precision highp float;\n"

    "uniform samplerRect aTexture;\n"


    the error here is at line 4, where the errorstring do refer to the variable by it's name 'aTexture'.

    One of the links DP brings refers to some d2Texture-trouble, but, as you see, the simple shader breaks on even the simplest defining a variable. .. changing my entire texture-setup will be next to impossible, and probably not solve the real problem, whatever that is.




    I've had a look at the context used, and I cannot find anything suspect about it. I'm using GLFW, setting a forward_compatible, core profile and adding
    "#version 330 core \n" to all shaders as well as in the context-request minor, major. If I have used anything depricatable, the compilation on the win7 mashine would have warned me.

    I do have attempted to update the graphics driver but probably have been dismissed with 'you already got the best'
    If I should look for drivers elsewhere but at the vendor of the mashine or GPU/CPU (it's dual) I'll be blank on what and how.


    I suppose that this is the sweet revenge in an ongoing war

  8. #8
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,546
    Quote Originally Posted by CarstenT View Post
    I suppose that this is the sweet revenge in an ongoing war
    It's up to you how much effort this is worth. Personally, I'd just pick up an inexpensive NVidia GPU and install NVidia graphics drivers. Then you can move away from tripping over driver issues and onto solving more interesting problems. Later on if/when you need more GPU horsepower, you can consider an upgrade.

    But you said this was a laptop. Sorry. That's one reason I avoid them -- upgradability on those things stinks.

  9. #9
    Intern Contributor
    Join Date
    Jul 2013
    Posts
    96
    hi dp,
    If I get you right: this pc has the gpu emulated on the cpu .. no physical stuff to replace.
    A previous laptop of mine was graphics-driver updatable .. the default driver did indeed ignore opengl.


    wasn't the problem of missing compatibility not solved by the arrangement between Microsoft (and others) and openGL? .. as a prerequisit for making software that involves graphics, a prerequisit for corporation?
    I want to know what I'm doing wrong or who is responsible for the foul-up. Microsoft is my obvious suspect. This would .. back in the day .. stir quite an uprore. Why doesn't it? The problem is general enough to involve two of my two win10 laptops.


    dp, tell me: how do I dump two years of intense work into the bin, or live with the fact that my work is not presentable on modern pc's?

  10. #10
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,546
    Quote Originally Posted by CarstenT View Post
    If I get you right: this pc has the gpu emulated on the cpu .. no physical stuff to replace.
    Probably. As I mentioned before, check the specs of your laptop or run GPU-Z or similar program to be see if your has another GPU in it. Some laptops have both the on-board Intel GPU in the CPU chip as well as an NVidia GPU which can render frames alongside it, and you can toggle rendering between these two GPUs. You can also just check for the presence of another GPU in your Device Manager (look under "Display Adapters").

    wasn't the problem of missing compatibility not solved by the arrangement between Microsoft (and others) and openGL?
    Before you go there, you should verify that your problems are definitely not due to something you're doing wrong. It doesn't sound like it, but we should be sure. Post a short, stand-alone test program that illustrates your problem for folks to review and try locally. If your issue isn't due to an error on your part, then...

    This isn't whether graphics drivers can work well on Windows "in general". This is an issue of the quality of graphics drivers written by GPU vendors.

    Some GPU vendors "are" producing graphics drivers with high quality and capability. Some are not. As always, as a consumer you have to be aware of which vendors are which and make your hardware purchases accordingly.

    dp, tell me: how do I dump two years of intense work into the bin, or live with the fact that my work is not presentable on modern pc's?
    If in-fact your problems are due to driver quality (yet to be proven), you have several choices: 1) Figure out how to work-around the issues in the graphics driver that you have, 2) Punt that and just chose GPUs from vendors with better graphics driver quality, or 3) Run an OpenGL implementation the executes the pipeline on your CPU (e.g. Mesa3D).

    Nothing so drastic as dumping years of intense work. Just vote with your dollars like the rest of us do.
    Last edited by Dark Photon; 11-16-2018 at 06:41 AM.

Posting Permissions

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