Examples using Display Lists?

I'm interested in building up a graphics library for an upcoming project. However, for displaying the primitives I don't want to use the GP FIFO intensive direct drawing method and would instead like to use display lists to accomplish a higher theoretical primitive throughput.

Now based on my knowledge of the GX_BeginDispList, GXEndDispList, and GXCallDispList functions my programs only end up crashing even attempting to draw the most basic QUAD. So, does anyone have an example that creates one or more primitives using the display list architecture in libogc?

I'm not aware of any example but I was planning to play with Display List someday so...

could you post your code somewhere ?
it' s probably a memory alignment or display list size issue

also, I think you have to invalidate the memory range (DCInvalidateRange) used by your display list before writing GX commands, to ensure data is cache coherent.

Cache invalidate is required each time external hardware is going to access CPU RAM (the memory array is indeed accessed by GX hardware between the _Begin and _End commands)

Hi Armin & Ekeeke,

I had trouble getting the GX_BeginDispList() and GX_EndDispList() functions to work. The Wii hangs at the first GX_DrawDone() call I issue, after creating the list using these two functions. When I dump the display list memory to a file, after calling these two functions, the memory is always at its default values. I do call DCInvalidateRange() on the memory before I ask GX to write to it.

I was able to generate a display list by hand, and feed that to GX_CallDispList(). Here's an example which draws a quad in the center of the screen with a display list. In the example, I wrote functions that emulate the GX_Begin, GX_Position*, etc, calls, but instead of writing to the GX fifo, these write to a global display list array.

Hi

after a look into those functions i figured some minor bugs.
Those bugs should be fixed now. Thanks to Michael for giving the memory hint.
It showed that i linked the DL fifo to the wrong point (GP instead of CPU).
The changes are commited to SVN already. So happy testing.

regards
shagkur

Fantastic news there shagkur. Any idea when the next release of devKitPro will include these changes?

They're already on SVN, you can download them yourself, or just wait for the next release. The next release will be whenever shagkur and wintermute feel it's appropriate, I guess.

Thanks a lot shagkur...
However, I can't found this fix (including the SYS_Fontxxx stuff) on SVN
anyone know if the libogc git is still alive somewhere ? it seems to have been removed from hackmii



Edited 1 time(s). Last edit at 02/02/2009 10:14AM by ekeeke.

Can we get an example posted up ArminTamzarian ? :D (or shagkur)

ekeeke: Both fixes, the Display list fix and the SYS_FontXXX fixes, are in the SVN. if you want to be sure then browse thru the SVN Webinterface on [sourceforge.net]

regards
shagkur

ok thanks
it seems like I was using a bookmark pointing me to the CVS (and not SVN) version

this one is not up-to-date, I never noticed both were co-existing in sourceforge :-/



Edited 1 time(s). Last edit at 02/02/2009 03:45PM by ekeeke.

Okay, so I created a libogc project, imported the libogc trunk from SVN, compiled the project to a bleeding edge library, and tested the most recent changes. The result? Same as before.

It seems that simply calling the GX_BeginDispList function causes the Dolphin emulator to hang. I have not had a chance to test the code on Wii hardware yet. Can anyone else confirm this?

ekeeke: Well CVS still exists but isn't maintained anymore. You _have_ to switch to SVN.

Once again, can anyone confirm or deny the functionality of the GX_*DispList functions? I've still not been able to get these functions to- well... function at all.

Tested on native wii hardware?

Quote
shagkur
Tested on native wii hardware?

As in just testing the code on an actual Wii rather than an emulator.

Quote
ArminTamzarian

Quote
shagkur
Tested on native wii hardware?

As in just testing the code on an actual Wii rather than an emulator.

I think it was a "yes" or "no" question. :)

Quote
BHSPitMonkey

Quote
ArminTamzarian

Quote
shagkur
Tested on native wii hardware?

As in just testing the code on an actual Wii rather than an emulator.

I think it was a "yes" or "no" question. :)

I dunno, rather safe than sorry. I'm known for being overly wordy. :)

Okay, did a little bit of investigation. The code still appears to hang on the Wii hardware just as it does on the emulator.

I did some testing against the trunk of libogc and found that the following code is causing the hang:

static __inline__ void __GX_ResetWriteGatherPipe()
{
	while(!(mfwpar()&0x1));
	mtwpar(0x0C008000);
}

Since I'm not really sure what this code does I'm not really sure what needs to be done to alleviate the problem. So I guess you can consider this a bug report more than anything.

ArminTamzarian: indeed that's a bug. i interpreted the flag the wrong way in the condition.
it should be "while(mfwpar()&0x1);". i fixed that and already commited it.

sorry for the hassle

regards
shagkur

Okay, just completed some more testing and wanted to share my current... strange findings.

I updated to the most recent SVN release, compiled, and compiled my test program. I'm getting another hanging problem, but this time in a new location. It appears that suddenly and without warning the call to GX_SetCPUFifo from within GX_BeginDispList is now causing the error. Specifically line 1295 in gx.c as highlighted below seems to be causing some sort of error.

void GX_SetCPUFifo(GXFifoObj *fifo)
{
	u32 level;
	
	_CPU_ISR_Disable(level);
	_gxcpufifoready = 0;
	_cpufifo = (struct __gxfifo*)fifo;
	if(_cpufifo==_gpfifo) {
		_piReg[3] = MEM_VIRTUAL_TO_PHYSICAL(_cpufifo->buf_start);
		_piReg[4] = MEM_VIRTUAL_TO_PHYSICAL(_cpufifo->buf_end);
		_piReg[5] = (_cpufifo->wt_ptr&0x1FFFFFE0);
		_cpgplinked = 1;
		
		__GX_WriteFifoIntReset(GX_TRUE,GX_TRUE);
		__GX_WriteFifoIntEnable(GX_ENABLE,GX_DISABLE);
		__GX_FifoLink(GX_TRUE);

		_CPU_ISR_Restore(level);
		return;
	}
	if(_cpgplinked) {
		__GX_FifoLink(GX_FALSE);
		_cpgplinked = 0;
	}
	__GX_WriteFifoIntEnable(GX_DISABLE,GX_DISABLE);

	_piReg[3] = MEM_VIRTUAL_TO_PHYSICAL(_cpufifo->buf_start);
	_piReg[4] = MEM_VIRTUAL_TO_PHYSICAL(_cpufifo->buf_end);
	_piReg[5] = (_cpufifo->wt_ptr&0x1FFFFFE0);
	_gxcpufifoready = 1;
	_CPU_ISR_Restore(level);
}

Seeing as how this function is so rarely used (only other place is within the GX_Init function) I'm not sure if this function is implemented correctly or if there is an error in the fifo parameter that was built and sent to the function.

Hope this helps and thanks for your continued work shagkur.