19 replies to this topic

[Nicholas Christopher]

What would be the best approach to dealing with this problem.

What I mean is where should I look first. And so on...

Nicholas

[Sol_HSA]

You could start by describing the platform you're hitting it on. I've never hit that error, and on desktop windows, you pretty much shouldn't ever hit it.

[Nicholas Christopher]

Essentially I'm writing a post processing module with the PBuffer. And the code works, its only when I transpose it to my main application from my test application that it doesn't.

At a point in the code I call these three funcs(below). Now I know glBindTexture will work even if I get the OUT_OF_MEMORY error, It just deals with it.

But I think (maybe I'm not sure) wglBindTexImageARB does fail. This is after
some tests I have performed, but I am strill doing more testing to determine
if its wglBindTexImageARB or glCopyTexSubImage2D failing permanently.

glBindTexture
wglBindTexImageARB
glCopyTexSubImage2D


My card GeForce 5700 fx go. 128 Meg on Windows XP Media Center

Is their a way around wglBindTexImageARB
and is their a way around glCopyTexSubImage2D without using read / draw pixels.

Nicholas

[Nicholas Christopher]

What is weird is if I run my main application and my test application
they both work if run independently . I don't see what is the difference.




Nicholas

[Kenneth Gorking]

Nicholas Christopher said:

But I think (maybe I'm not sure) wglBindTexImageARB does fail. This is after
some tests I have performed, but I am strill doing more testing to determine
if its wglBindTexImageARB or glCopyTexSubImage2D failing permanently.

Neither wglBindTexImageARB or glCopyTexSubImage2D will cause an Out Of Memory error. See here and here. How often are you checking for errors? It may be occuring before these calls, or even after, if you only check once per cycle...

[Nicholas Christopher]

You are definitely right about that Kenneth.

I'm still looking to track down the problem. Its that all the other functions
continue to work disregarding the error, but wglBindTexImageARB or glCopyTexSubImage2D fails .. I'm going back to review my initialization
code.

I'm also looking into the fact that I have multiple GL viewports (TOP,RIGHT,LEFT) etc.. and whether this may be the problem.

[Reedbeta]

You should check for the error after every GL call. (You can put these checks inside #ifdef blocks so you can compile them out again once you've identified the error.)

[Sol_HSA]

You may wish to try out gDEBugger by graphics remedy (http://gremedy.com/).. it's not free, but it has a trial mode that will let you test if it can help you with the problem.

[SigKILL]

.. or glExpert ( http://developer.nvi...xpert_home.html ).

[Nicholas Christopher]

thanks guys.. I will try these 2 apps and widen my error testing.. boring as it may be to do.

Nicholas

[kusma]

Kenneth Gorking said:

Neither wglBindTexImageARB or glCopyTexSubImage2D will cause an Out Of Memory error. See here and here.

Wrong. All OpenGL calls can result in GL_OUT_OF_MEMORY. Read up on section 2.5 of the OpenGL 2.0 spec, especially the following wording:

"Several error generation conditions are implicit in the description of every GL
command:

• If a command that requires an enumerated value is passed a symbolic constant
that is not one of those specified as allowable for that command, the
error INVALID ENUM error is generated. This is the case even if the argument
is a pointer to a symbolic constant, if value pointer to is not allowable
for the given command.
• If a negative number is provided where an argument of type sizei is specified,
the error INVALID VALUE is generated.
• If memory is exhausted as a side effect of the execution of a command, the
error OUT OF MEMORY may be generated.

Otherwise, errors are generated only for conditions that are explicitly described in
this specification."

And besides from that: never ever take the man-pages for a definite source of information about OpenGL, they are loaded with errors. Unfortunately, it takes a while getting used to reading the spec.

[Nicholas Christopher]

Well.

If you have been following my other thread at all on devmaster
http://www.devmaster...read.php?t=9859

This means that the 3.1 gDebugger version won't run on my PC..
The 3.1 version installation crashes , I have logged a report on their forum.

So I tried to simply extract the msi's files, and run the application and it crashes
also, complaining about my nvidea drivers. I was hoping it was simply opengl32.dll

So it looks like I can't use gDebugger, tried to find an older version unsuccessfully.

I know what you are going to say here.. update my drivers.. but I don't think I can.. toshiba laptop.

So now I'm back to using glError... Uhhhh... man is that going to be a lot of work.



Nicholas

[kusma]

Call the following macro after all gl-calls you suspect might trigger the error. Inspect your input to the function that tuns out to cause the error. It shouldn't take too much time to track it down.

#define TRACE_GL_ERROR() do { GLenum err = glGetError(); if (GL_NO_ERROR != err) printf("*** GL error: 0x%X at %s:%d\n", err, __FILE__, __LINE__); } while (0)

[Nicholas Christopher]

So it seems that either the pBuffer, or wglBindTexImageARB , or glCopyTexSubImage2D, does not work with multiple opengl window frames. Or a combination of the three. (2windows + pBuffer + wglBindTexImageARB) = failure.

Well it actually does work, but only on the LAST opengl frame created.

I modified my test application to the images below, composed of 3 window
frames, the application window, and the two opengl windows. (I don't mean viewports) seen side by side.


The first image,shows it working. The thumbnail shows what is rendered in the pbuffer. And the teapot rendered properly in the last window created.

image1:


I swap the opengl window frames and almost nothing happens. It still renders
a black screen to the wrong window, even if you make the other window current. The white window frame being
the window it should be drawing to.

image2:


Now I will go back and modify my main application and pray I was right. ;)

Thanks kusma for the code snip.

I added a snippet of code to show the window creation.

DWORD dwStyle = WS_CAPTION | WS_POPUP |  WS_SYSMENU | WS_VISIBLE | WS_MINIMIZEBOX;
DWORD dwExStyle = WS_EX_APPWINDOW | WS_EX_WINDOWEDGE;

WNDCLASS wndClass =
    {
        CS_OWNDC, WinProc, 0, 0,
        g_hInstance, LoadIcon(g_hInstance, "IDI_APP"), LoadCursor(0, IDC_ARROW), 0, 0, "HDR"
    };

	RegisterClass(&wndClass);
	g_hWndParent = CreateWindowEx(dwExStyle, "HDR", "HDR", dwStyle, 0, 0, VIEW_WIDTH+10, VIEW_HEIGHT+10, 0, 0, g_hInstance, 0);

GetClientRect(g_hWndParent, &r);


    hWnd =osInit("HDR2" ,0,0, VIEW_WIDTH/2, r.bottom, OS_OVERLAY /*| OS_FSAA*/, 0);

/*	hDC =window.hDC;
	hRC =window.hRC;
	texture = window.texture;
	hBuffer = window.hBuffer; */

	hTmp =osInit("HDR3",  VIEW_WIDTH/2, 0,VIEW_WIDTH, r.bottom, OS_OVERLAY /*| OS_FSAA*/, 0);

	/*g_hWnd = hWnd;
	window.hDC = hDC;
	window.hRC = hRC;

	window.texture =texture;
	window.hBuffer = hBuffer; */
	
    //osWaitVsync(0);
	//ShowWindow(g_hWnd, SW_HIDE);
    init();
	//ShowWindow(g_hWnd, SW_SHOW);

    while (!done)
    {
    // windows vanilla loop
    }

[dave_]

Nicholas Christopher said:

Well.

If you have been following my other thread at all on devmaster
http://www.devmaster...read.php?t=9859

This means that the 3.1 gDebugger version won't run on my PC..
The 3.1 version installation crashes , I have logged a report on their forum.

So I tried to simply extract the msi's files, and run the application and it crashes
also, complaining about my nvidea drivers. I was hoping it was simply opengl32.dll

So it looks like I can't use gDebugger, tried to find an older version unsuccessfully.

I know what you are going to say here.. update my drivers.. but I don't think I can.. toshiba laptop.

So now I'm back to using glError... Uhhhh... man is that going to be a lot of work.



Nicholas

<flippant>Install newer drivers, use FBO's you would have saved yourself tonnes of hassle</flippant>

[Nicholas Christopher]

@ dave_

I updated the drivers on my laptop in the past and it blue screened windows.
I needed to totally recover OS from install CD's

Actually I just tried again to upgrade the drivers, and my product is not even supported by nvidia .

GeForce FX GO 5700, the GeForce FX 5700 is, but not the mobile card.


Nicholas

[dave_]

Try this: http://www.fredfred....ceware-drivers/

Edit:
But also make sure you have a system restore point so you can always roll back the OS to before you mess with the drivers (if it blue screens)

[Nicholas Christopher]

Hi dave_

I think you missed this on my previous reply.

Quote

Actually I just tried again to upgrade the drivers, and my product is not even supported by nvidia .

GeForce FX GO 5700, the GeForce FX 5700 is, but not the mobile card.

Nicholas

[Kenneth Gorking]

Nicholas, as the link provided by _dave says:

Quote

NVidia does not officially support GeForce Fx Go cards in their ForceWare drivers. But, who wants to wait until laptop manufactures release new version of drivers?

There is solution. Download official ForceWare driver and unzip to any folder. Replace nv4_disp.inf with this file (added Go5200 lines and fixed according Matt's suggestion). Finally go to Device Manager/Display adaptors/GeForce FX Go5200 graphic card and update driver with the new one.

So give it a go, it might work.

[Nicholas Christopher]

Sorry, my error I should have gone to the link. ;)

I will try..

Quote

Well I was a success THANK YOU :) ;) :) "dave_" ;) ;) ;)

And thanks for pushing the point Kenneth.. Its like I say, I usually understand after its been explained more than once.

Nicholas