Gerard Parareda, I cannot say when the next release will appear in public. If it were me and I had that uncertainty, I'd go with what works. As noted in the separate thread, this defect is fixed and will appear in the next release. Per Bug Report for driver 14.9
Re: When is the next driver going to be released?
Re: When is the next driver going to be released?
I downgraded to 14.9 and works fine now. I will check these threads every now and then to see if it is fixed in a newer release.
Also, I stumped upon this news article:
Steam Community :: Group Announcements :: Leadwerks Game Engine
Thanks for the help
Re: Mantle Headers
It's kinda sad these headers won't be released by AMD as I'm pretty sure there'll be some unofficial ones buzzing around soon. Seems a rather bizarre decision as the various mantle DLLs are already in the AMD drivers and the specification gives all details of the API.
It's be fantastic to be able to play around with Mantle before Vulcan appears.....
@computerquip If you do start to put together some headers it'd be great to see them posted!!!
Mipmap levels >0 for Sparse a texture 2d array are always black?
I have been learning the most recent OpenGL techniques by making a Quake 2 Renderer. I am having an issue using a sparse texture 2d array. I have the code up on github here: discoloda/Quake-2 · GitHub in ref/gl3/texture.cpp, the pertinent bits are Manager::Storage and texture_get_managed.
The first attachment is where Sparse is enabled, the second is where sparse is disabled.
Re: Mantle Headers
It seems likely they cant release the headers because they contain information that they cannot legally released. Probably related to DX12 or Vulkan.
atiogl.xml
Hi guys
I want to ask you,if you could add to newer drivers packages atiogl.xml,as I'm using Poser Pro or other 3D SW where I'm suffering with strange OpenGL performance,as per this thread Poser Pro 2014 problems again
Not sure why those files are missing in newer CCC packages,but if its possible add them there
Thanks,Jura
Re: atiogl.xml
Hi,
Current drivers no longer use atiogl.xml for configuration and so including it (or copying from an older system) won't have any effect. This is not an unintentional omission - current drivers use a different mechanism for recording user preferences and per-application settings. In the thread you link to, the user mentions Radeon HD 4xxx series (which we no longer support with new drivers) and driver version 13.9, which is more than 18 months old. We can only really support and comment on issues related to currently-supported hardware and up-to-date drivers.
If a similar issue is happening for you with recent hardware and up-to-date drivers, let us know and we'll look into it.
Thanks,
Graham
Transform Feedback Objects and AMD Radeon HD 7900 series
I seem to be having problems with Transform Feedback Objects work with an AMD Radeon HD 7900 series GPU. Basically I'm using the OpenGL Super Bible Chapter 7 example on spring mass systems and transform feedback. In fact, I'm running the source code directly from the website here. The sample by itself works perfectly. I wanted to try and use TFO's and so instead of using the calls to glBindBufferBase in the render function, I created two TFO objects in the startup function and just bind the opposite TFO to VAO in the render function (where the original glBindBufferBase calls were). The problem that I'm seeing is that, if all I change in the sample is create the TFOs and replace the bind inside the render, the buffers don't seem to update anymore. However, 1) if I change the number of iterations per frame to an odd number, 2) if I query NUM_PRIMITIVES_WRITTEN and immediately get the result of the query after glEndTransformFeedback, or 3) if I call glFlush after glEndTransformFeedback, then the sample works as I expect it to, storing the transformed vertices to the correctly bound buffer of the TFO. I've tried this exact code on an NVidia card, on a Mac Pro with AMD Fire Pro cards and multiple Macbook Pro's and all work as expected without any need for the above 3 changes to the render function. Any help would be very much appreciated!
Re: atiogl.xml
Hi Graham
Thanks for reply,really appreciated for this
I've same OpenGL issue on the Sapphire R9 290 Tri-X and I've tried all current drivers,but this issue has persisting on the those drivers/packages,currently I'm using 14.2 with Driver package: 13.251-131206a-167984C-ATI
I would want to use new features like Mantle or new OpenGL,although I'm not gaming on my PC,but still sometimes I would love to play game without the any problems
This posted thread I've started over on RDNA(my name there is jura)
If you could have look on this issue I would be very appreciated for this
Thanks,Jura
Re: GLSL compute shader incompatibilities
Hi, thanks for the code. It worked for me also, so I experimented a little bit found that there is important the size of the buffer. When the size of the buffer is multiple of 16, then everything works. But in my case, I store an array where each element contains 12 bytes, so the total size of the buffer is multiple of 12. I tried with values 36 and 48.
Direct State Access on Radeon 5870
With this ever be supported on this card?
glMultiDrawElementsIndirect() system hangs
With the latest beta driver 15.4 on a Radeon 5870 powered laptop I have experienced system hangs consistently when drawing a zero count number of elements. I have had quite a few system hangs and strange behaviour around related functionality since a few driver versions ago in fact which has made it difficult to track down the different cases - with the zero count elements being the only one I have managed to pin down. In a few cases I have found I have made mistakes but in others I am not convinced I was in error and of course a full system hang is a pretty awful result regardless in gl debug mode.
Testing the same applications on an IntelHD 4000 seems to have no issues though. I'm not convinced I haven't done something wrong still though, but I wondered before I dig even deeper, if there were any current known issues around glMultiDrawElementsIndirect() functionality with the latest drivers on the Radeon 5870?
UPDATE:
One particular problem I have been seeing now is that missing commands seem to randomly occur. This goes away if I replace the glMultiDrawElementsIndirect() with multiple glDrawElementsInstancedBaseVertexBaseInstance() calls....
The problem also seems to go away if I issue a glMultiDrawElementsIndirect() for single elements within the buffer rather than all at once? There are no errors or warnings from the debug context.
Re: When is the next driver going to be released?
I downgraded to 14.9 and works fine now. I will check these threads every now and then to see if it is fixed in a newer release.
Also, I stumped upon this news article:
Steam Community :: Group Announcements :: Leadwerks Game Engine
Thanks for the help
Re: Direct State Access on Radeon 5870
This card is available for free at High performance computing on graphics processing units | hgpu.org. I think, you can test this there.
Direct State Access on Radeon 5870
Will this ever be supported on this card?
Re: glMultiDrawElementsIndirect() system hangs
I found the cause - it seems it doesn't like a zero count of elements in the indirect draw structs for some reason? If I remove said null elements its all fine. But that's a bit worrying if I want to eventually generate those draws on the GPU instead of CPU...
Also if I use:
glMultiDrawElementsIndirect(GL_TRIANGLES, GL_UNSIGNED_SHORT, 0, 0, 0);
It draws something not _nothing_ but doesn't hang my system any more.
So I think that's a driver bug?
Re: glMultiDrawElementsIndirect() system hangs
Hi,
Just to be clear, it sounds like you're seeing two problems here. First is that if you have a single draw in the indirect buffer with a count of zero indices, then the GPU hangs. The second is that if you call glMultiDrawElementsIndirect with a draw count of zero, then you see corruption or hangs. Is that correct?
The first sounds like a known issue that we resolved many months - actually well over a year ago, so it is surprising if it came back, We'll have to investigate.
The second also sounds like a separate bug.
Do you have an indirect parameter buffer bound, or are you trying to use client memory for this? It looks from your code snippet it looks like you're using a buffer, but I want to confirm that.
Thanks,
Graham
Re: glMultiDrawElementsIndirect() system hangs
Hi,
Yes it appears that I encountered two problems. The main one is the indirect draw buffer with a count of zero (but not all elements were zero which I think is ok), and yes the second a glMultiDrawElementsIndirect() with a draw count of zero. However I had to discover the second (and guard around it to stop the system hang) to discover the indirect draw buffer problem. I am not sure if they were actually directly related in cause.
I had persistently mapped buffers for the indirect draw and the instance vertex stream (which consisted of 4 GL_INTs - one being used for the instanceID, and connected to vertex attribute 2). The index and vertex buffers used were allocated with buffer storage and mapped per frame (The vertex format from here had a position and texture coordinates that were a compressed 8 bytes in size, 16 bit indices).
I posted some additional info in the related question top opengl.org here: https://www.opengl.org/discussion_boards/showthread.php/186128-glMultiDrawElementsIndirect%28%29-problems?p=1265880#post1265880
Since then I have moved a few things around as I am transitioning things to more modern OpenGL but I believe the problem is still happening - as all I have changed currently is using a persistent staging buffer to upload index/vertex data which is then copied to GPU only accessible buffers used for rendering (draw indirect and instance data still coming from a persistently mapped CPU accessible buffers).
Also it would be good to know while I am here if it is recommended against to use the same persistent staging buffer for both index and vertex data at the same time? - I am writing a mix of index and vertex data in the stream together currently that then get copied out to their respective GPU side index/vertex buffers.
Thanks for your response!
Re: Direct State Access on Radeon 5870
I have the card and it doesn't expose DSA in OpenGL, hence my question...
Re: Direct State Access on Radeon 5870
Let me see if I can dig something up. I may not be able to answer a question like "will this ever be supported." But let's find out.