glDeleteProgramsARB() : I don't understand it's purpose

The official description is kind of vague to me:
[b]
Programs objects are deleted by calling

  void DeleteProgramsARB(sizei n, const uint *programs);

<programs> contains <n> names of programs to be deleted.  After a program
object is deleted, its name is again unused.  If a program object that is
bound to any target is deleted, it is as though BindProgramARB is first
executed with same target and a <program> of zero.  Unused names in
<programs> are silently ignored, as is the value zero.

[/b]

Am I supposed to use it before my program terminates (assuming I have bound and created a valid vertex program)? What happens when I don’t call it?

Any decent driver model should be able to recover all used resources when a process exits.

However, if you have a program that runs for very long, and loads/unloads a lot of different programs (say, shaders in a modeling program, or a game with 40 levels) then it’ll conserve resources to delete what you’re not using.

Unfortunately, it’s fairly easy to argue that 16-bit Windows doesn’t have a decent driver model, so you’re probably safer in calling DeletePrograms as soon as possible when you know you’re not going to need the programs anymore. It’s known for not cleaning up after crashing programs or shift-F5 in the MSDEV debugger. Clean program exits usually clean up, though.

Cool, thanks.

DeletePrograms() is little more than a glorified free(). It can help reduce your resource consumption, and it gives the driver one less thing to manage.

If your program happens to be in use when you delete it (for previous vertices), the driver should take care of any necessary synchronization.

Originally posted by jwatte:
Unfortunately, it’s fairly easy to argue that 16-bit Windows doesn’t have a decent driver model, so you’re probably safer in calling DeletePrograms as soon as possible when you know you’re not going to need the programs anymore. It’s known for not cleaning up after crashing programs or shift-F5 in the MSDEV debugger. Clean program exits usually clean up, though.

I didn’t think 16-bit Windows supported OpenGL… :slight_smile:

Leathal.

This is not much different from if your program fails to call free() after using malloc(). Win9x and WinNT both do just fine cleaning up after that.

Smart applications will avoid having dangling references outstanding to old textures/programs/etc., by deleting them when they’re done and/or putting a new object on the old ID.

  • Matt

for compatibility, win9x/me core components are essentially “wrapped” 16-bit equivalents from win3.1 enhanced mode version… sad but true. in particular, most gdi/graphical and kernel/memory components are “as originally seen on tv” (ie win 3.1 lol) so a crash/debug break can mess with the driver’s 16 bit context… win nt/2k/xp are not that crap, though.

[edit]nt kernel and its derivatives (2k/xp) are okay, though (unless you’ve got really cack drivers)

[This message has been edited by mattc (edited 10-28-2002).]