[REF/DEV] KaiserGL SDK (for Imageon on Qualcomm 72xx devices)

[flysoftter]

my g900 can not run demos, why? can you rebuilding you demo programs with g900? Thank you very much!

[toastedlogic]

This may be entirely inaccurate, but IIRC the ppc ports of games like quake, duke3d, etc have problems with wm6.1 roms due to the new gx.dll... any way you graphics programmers could look into getting these programs working again for our wm6.1 devices? Maybe even enhance them?

I figured it was worth a shot, hehe

[liomojo]

Originally Posted by flysoftter my g900 can not run demos, why? can you rebuilding you demo programs with g900? Thank you very much!

when he finishes with the Kaiser development, Ycavan said that he will try to make the same thing for our nv5500 chip. so you have to wait.
you can run the nvidia demos he gave us, some pages before.

[NuShrike]

void PowerEvent(HANDLE hMsgQ, BYTE *buf, const size_t bufsize)
{
	DWORD bread;
	DWORD msgq_flags;

	if (ReadMsgQueue(hMsgQ, buf, bufsize, &bread, INFINITE, &msgq_flags)
		&& bread >= sizeof(POWER_BROADCAST) )
	{
		POWER_BROADCAST *pbc = (POWER_BROADCAST *) buf;
		switch(pbc->Message)
		{
		case PBT_TRANSITION:
			if (pbc->Flags & POWER_STATE_ON)
			{	// going into suspend
			}
			break;
		}
	}
}
DWORD WINAPI PMNotifyThread(LPVOID param)
{
	CSomeObject *frame = static_cast<CSomeObject *>(param);

	static const unsigned bufrec_size = sizeof(POWER_BROADCAST) + MAX_PATH + 1;
	MSGQUEUEOPTIONS_OS msq_options = {
		sizeof(MSGQUEUEOPTIONS), MSGQUEUE_NOPRECOMMIT, 3, 4096, TRUE
	};
	HANDLE hPwr[2], msgQ;
	hPwr[0] = frame->hPwr_exit;
	msgQ = hPwr[1] = CreateMsgQueue(_T("<optional name>"), &msq_options);

	if (hPwr[0] && msgQ && RequestPowerNotifications(msgQ, PBT_TRANSITION | PBT_RESUME))
	{
		BYTE buf[bufrec_size];
		for(;;)
		{
			switch(WaitForMultipleObjects(2, hPwr, FALSE, INFINITE))
			{
			case 0 - WAIT_OBJECT_0:		// got exit event
				goto exit;
			case 1 - WAIT_OBJECT_0:		// got power event
				PowerEvent(msgQ, buf, bufrec_size);
				break;
			}
		}
exit:
		CloseMsgQueue(msgQ);
	}

	return 0;
}

int foo()
{
	hPwr_thr = CreateThread(NULL, 0, PMNotifyThread, this, 0, NULL);
}

[NuShrike]

For a GL app to survive suspend in the current HTC-CA GL driver state, it needs to catch the suspend (using the previous code framework) and then reinitialize the graphics state as if it was restarted. This is without throwing away any other (AI/program) states.

The problem is it means the current GL context and the associated GL window surface needs to be destroyed (eglDestroySurface() and eglDestroyContext() ) and recreated from scratch again.

This is workable for an app designed for this, but not for hacking existing apps such as TF3D that expects the driver to do all the work.

Hacking the driver would be a lot of work because the entire graphics state needs to be duplicated and tracked such as current texture object, current vertex object, vertex buffer objects, etc.

[dpwFalken]

Hi,

I've read about catching the suspend state, I'll try your code tonight after work, thanks .

Have you tried running more than one 3D App at the same time? I tried to launch a 3D App from Manila 3D and it failed. This resulted in the device running at nearly 100% and Task Manager being unable to kill off the App process. I've tried two sample 3D Apps to confirm it is not an issue with Manila 3D and get the same result. I assume that this is a driver issue. I debugged the App and found that it failed to initialise the D3D device (its a Direct3D App) and then shutdown. It never fully exited though, got stuck somewhere in Windows. Wondering if you've seen something similar. At the moment I'm not that worried as I just make sure I'm not running more than one 3D App at the same time. It is something to be aware of as will require a soft reset if you try launching a 3D App while one is already running.

[NuShrike]

Originally Posted by dpwFalken I debugged the App and found that it failed to initialise the D3D device (its a Direct3D App) and then shutdown. It never fully exited though, got stuck somewhere in Windows.

From what I remember, D3D is a COM interface where only one program can be using the COM interface at a time so this is why D3D is bad.

However, the OpenGL-ES driver underlying the ATI D3D driver may support multiple instances from looking at the way it initializes its data structures. I haven't really investigated this yet since it's up to the application to NOT call eglSwapBuffers() and such when it's not the foreground application (we're not multi-CPU here).

TF3D/Manila doesn't handle it's not "foreground" very well such as with pop-up dialogs.

[dpwFalken]

Originally Posted by NuShrike I haven't really investigated this yet since it's up to the application to NOT call eglSwapBuffers() and such when it's not the foreground application (we're not multi-CPU here).

Thanks, that's given me some ideas to experiment with.

I've not found any info regarding restrictions on the use of COM, but the documentation is a little thin on the D3DMobile side compared to D3D on the PC. My App runs pretty well with the CA Drivers, just trying to address the things I've found that require a reset before posting it somewhere.

[NuShrike]

latest fixes and changes to KaiserGL SDK:
o fixed missing eglCopyBuffers() in libgles_cm.lib
o add function pointer type for secret eglGetColorBufferQUALCOMM() function -- you need eglGetProcAddress() to get access
o removed function prototypes for unsupported glGetLight*() functions
o synchronized with OpenGL ES 1.1.12 and EGL 1.4

[NuShrike]

Added a forwarder to remap hardcoded CL calls to the Imageon CM dll (meaning it can be installed right alongside the device, or HTC-CA, libgles_cm.dll). Tested with GLBenchmark CL on the Kaiser.

Let me know if some app crashes or is incompatible with the wrapper.

edit:
I believe this is a forwarder compatible with the Intel 2700g, but not the GoForce 5500. I'll have to make a different forwarder for the GoForce.

Verified apps:
Cube 2005
Hexen GLES
Doom GLES
Tony Hawk Pro Skater 2