| Summary: | openGL glDeleteBuffers does not delete buffers created using glGenBuffers | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Dan Allen <dan.j.allen> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Xorg.0.log
Output of command su -c 'lspci -nn' Output of command dmesg Test program |
||
Created attachment 80356 [details]
Xorg.0.log
Created attachment 80357 [details]
Output of command su -c 'lspci -nn'
Created attachment 80358 [details]
Output of command dmesg
Created attachment 80359 [details]
Test program
The attached freeglut program was also executed on both systems. This does not provide the expected results either.
Is this really a problem? Mesa might not always reuse buffer names, but that does not mean the buffer wasn't properly deleted. As far as I can see, OpenGL does not require name reuse. (In reply to comment #5) > Is this really a problem? Mesa might not always reuse buffer names, but that > does not mean the buffer wasn't properly deleted. As far as I can see, > OpenGL does not require name reuse. It's standard compliant, but it sounds like a symptom of a leak. (In reply to comment #6) > (In reply to comment #5) > > Is this really a problem? Mesa might not always reuse buffer names, but that > > does not mean the buffer wasn't properly deleted. As far as I can see, > > OpenGL does not require name reuse. > > It's standard compliant, but it sounds like a symptom of a leak. It's actually not a leak. glGenTextures/Buffers/Framebuffers(), etc call the _mesa_HashFindFreeKeyBlock() function. For speed, it simply returns the next previously unused integer. If we'd ever hit 0xffffffff (or whatever the new hash table's limit is) we'd resort to searching the hash table for a lower, unused ID. I doubt that any app/test has ever exercised that case though... (In reply to comment #5) > Is this really a problem? Mesa might not always reuse buffer names, but that > does not mean the buffer wasn't properly deleted. As far as I can see, > OpenGL does not require name reuse. If the buffer is being deleted I don't see this as a problem. My only question would concern context sharing. Does this implementation support context sharing, and if so, do the buffers retain the same name in the shared context? (In reply to comment #8) > (In reply to comment #5) > > Is this really a problem? Mesa might not always reuse buffer names, but that > > does not mean the buffer wasn't properly deleted. As far as I can see, > > OpenGL does not require name reuse. > > If the buffer is being deleted I don't see this as a problem. My only > question would concern context sharing. Does this implementation support > context sharing, and if so, do the buffers retain the same name in the > shared context? Yes, and yes. The name->object hash table for buffer objects is shared among contexts. (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #5) > > > Is this really a problem? Mesa might not always reuse buffer names, but that > > > does not mean the buffer wasn't properly deleted. As far as I can see, > > > OpenGL does not require name reuse. > > > > If the buffer is being deleted I don't see this as a problem. My only > > question would concern context sharing. Does this implementation support > > context sharing, and if so, do the buffers retain the same name in the > > shared context? > > Yes, and yes. The name->object hash table for buffer objects is shared > among contexts. Apologies for the error. This is obviously not a problem. Thanks for all the help. (In reply to comment #7) > If we'd ever hit 0xffffffff (or whatever the new hash table's limit is) we'd > resort to searching the hash table for a lower, unused ID. I doubt that any > app/test has ever exercised that case though... If there's no test for that path, that probably means it's broken? :) (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Is this really a problem? Mesa might not always reuse buffer names, but that > > > does not mean the buffer wasn't properly deleted. As far as I can see, > > > OpenGL does not require name reuse. > > > > It's standard compliant, but it sounds like a symptom of a leak. > > It's actually not a leak. glGenTextures/Buffers/Framebuffers(), etc call > the _mesa_HashFindFreeKeyBlock() function. For speed, it simply returns the > next previously unused integer. > If we'd ever hit 0xffffffff (or whatever > the new hash table's limit is) we'd resort to searching the hash table for a > lower, unused ID. Sounds good then. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Description of problem: Testing a working application using openGL (through JOGL) failed on Fedora 18. I was trying to find the cause of another problem but noticed that buffers created using glGenBuffers are not deleted when using glDeleteBuffers in the process. How reproducible: The following code is used in the display method of a JOGL application: int[] buffer = new int[1]; for(int i = 0; i < 5; i++) { gl.glGenBuffers(1, buffer, 0); System.out.println("Buffer Generated: " + buffer[0]); gl.glDeleteBuffers(1, buffer, 0); } Steps to Reproduce: 1. Execute a simple JOGL application with the above in the display method. Actual results: Buffer Generated: 1 Buffer Generated: 2 Buffer Generated: 3 Buffer Generated: 4 Buffer Generated: 5 Expected results: Buffer Generated: 1 Buffer Generated: 1 Buffer Generated: 1 Buffer Generated: 1 Buffer Generated: 1 Additional info: This has been reported in the Fedora bug reporting system. However, testing this in Ubuntu 13.04 gave the same results. I was recommended to report this directly at xorg.