@BSzili

Can you repeat your 2048x2048 texture tests on a 16 bit screenmode?

@BSzili

Can you repory your system config, including all versions of installed Warp3D components? Another developer is reporting that the same debug driver crashes his system.

@BSzili

Good.

Can you provide me with the debug output from the driver? I'm keen to see how the allocator is behaving this close to the limits of the underlying bitmap implementation.

The driver should be logging data to the debug buffer.

Cheers

Just a note regarding my earlier post. If you are using a RadeonHD based graphics card, the updated W3D_Picasso96.library is not relevant to your configuration.

The changes are relevant o R100, R200, Voodoo and Permedia configurations only.

Hi,

I didn't read the entire thread, but the early posts suggesting problems regarding the use of large textures ( > 1024 pixels wide) might be related to a bug reported here:

http://forum.hyperion-entertainment.biz/viewtopic.php?f=14&t=2955

There is a debug-build version 53.11 W3D_Picasso96.library available here which may (or may not) fix the issue but should help determine what's going on in the low level VRAM allocator for non SI cards (they use their own allocator):

http://extropia.co.uk/warp3d/

Username: warp3dbeta

For the password, PM me.

I tracked down the implementation of the function in question in the source:



As you can see, Remove() is invoked on the node. And, as I suggested my previous post, the kernel does indeed make changes to the node structure. From the Remove() documentation:




So yes, it's completely illegal to access ln_Succ *after* calling the function. Whatever value they had previously is overwritten by the call to execsg's Remove().

Quote:

I didn't say it freed a pool of memory. I said it (probably) freed the node. But it could do anything. The point is, the original code took the ln_Succ node's value *before* calling the L_FreeFiletype() on the node and not *after*. The main reason you do something like that before calling any function is because you know that member isn't going to be valid *after*.

Also, the whole argument about multiple threads and what not is irrelevant. Accessing the properties of any structure that has been freed is flat out wrong, regardless of whether you are in the same thread of execution or a different one.

Quote:




You can assume no such thing!

What if L_FreeFiletype() zeroes out the member pointers or assigns them some special "marked free for reallocation" value or anything? What if during the process, the kernel fills the space that was allocated with some special value when it's freed? And yes, there are debug builds which do this sort of thing to help developers identify the specific type of lunacy you are suggesting can be assumed ;)

Bottom line: you have no idea that it's safe to access the node after calling L_FreeFiletype() and the only reasonable thing you can infer from the original code is that it isn't.

Quote:

The point is that neither of us know what side effects L_FreeFiletype() have. However, my assumption that it frees the node and thus renders it's structure members invalid is based on what I would say is reasonable inference, when you look at the original code:



The comment, function name and "get the successor node before" strategy strongly suggests that this is the case.

Quote:

Without question.

Quote:

You don't need to know whether the list is shared or not to understand that referencing already freed memory is a big mistake. Look at the original code: there is a rock-solid reason that the next pointer is assigned the value of ln_Succ *before* the call to L_FreeFiletype() on the node.

Maybe you'll be lucky most of the time and the ln_Succ member at whatever address/offset the original node existed at a moment ago is still valid but to assume so would be foolhardy at best. Especially when you consider that OS4 is moving away from casual uses of Forbid() to prevent other tasks from pre-empting your code away and implements fast-turnaround slab allocators for structures. The chances that the memory your node was just in a moment ago will be recycled for someone else's use is likely greater than it was in 3.x.


-edit-

Quote:

I have to ask... really?

Look, Mutexes and Semaphores are there to ensure a resource is properly accessed in a concurrent environment. They are not there to protect you from playing Russian Roulette with pointers.

You have no idea what L_FreeFiletype() is going to do to the memory your node lives in. Probably, it will just free it, but it could do anything. Suppose these nodes are created by an allocator function. For all you know, the code might manage a private pool of them. You have no way of knowing what this function does to the memory occupied by the node. It might re-assign them to some value, resulting in a DSI when you try to dereference the pointer you read back. Or maybe it just zeroes it, in which case, your loop finishes early without processing the rest of the list which results in a memory leak (and perhaps other resources too).

Quote:

This code is dangerous. You will note that the iteration statement of the for() loop uses the node pointer after you have freed it. Other problems aside, the original code had some protection against this. There are other loop constructs that would be better suited, but for minimal changes:

@thellier

W3D_SetDrawRegionTexture() is not implemented and moreover is removed in the latest versions of the main library and drivers. Calling it due to an outdated interface definition is probably not a great idea.

@Thellier

Colourspace conversion from YUV <-> RGB can be achieved with matrices.

For normalized (0.0 - 1.0) values:


It's the sort of thing AltiVec should be able to do pretty well if used properly.

@freddix

It will require an API change for Warp3D. I've submitted an RFC for the necessary changes (which includes adding developer support for 16-bit Z buffer selection) and I'm waiting to hear back. I can't just change the API because I feel like it.

Quote:

In Warp3D, the anisotropy value will most likely be an enumeration that describes the maximum number of samples, rather than a GL-style floating point value, perhaps something like this:

enum {
W3D_ANISOTROPY_1X,
W3D_ANISOTROPY_2X,
W3D_ANISOTROPY_4X,
W3D_ANISOTROPY_8X,
W3D_ANISOTROPY_16X
};

It will be MiniGL's job to worry about float -> enum selection.

Quote:

Actually, to put this feature under developer control will require an update to the Warp3D API*, not just MiniGL.

*addition of new MinFilter enumeration values for anisotropic filtering
*addition of a method to set the degree of anisotropy for a given W3D_Texture