Tiled Resources where hardware and API take care of most of the managing of the tiles.
Dynamic loading of tiles with hardware works better than previous software approaches.
Allows more efficient use of memory.

http://tweakers.net/nieuws/89972/mic...resources.html
Would like to be able to specify to always load the mipmap of the upper level.
When developing counterpart allow for automatic mipmap fall-back with just fall further up to the upper, least detailed mipmap or what's behind it or a default color or something.

If the software problem of having to do overlapping borders is also affecting OpenGL using software algorithms please provide things to having to avoid doing this without hardware tiled resources.

And being able to interact, overwrite buffering algorithm for each tiled resource individually.

There is already an extension for that, which is even more powerful than DX11.2 tiled resources (see AMD_sparse_texture), in fact, pretty much this time DX "borrowed" from GL, like they did with most of their DX11.1 features.

Last edited by aqnuep; 06-29-2013 at 01:39 PM.

Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/

There is already an extension for that, which is even more powerful than DX11.2 tiled resources (see AMD_sparse_texture), in fact, pretty much this time DX "borrowed" from GL, like they did with most of their DX11.1 features.

and it looks like we're gonna wait until opengl 5 for this functionality to become actually any useful by making it into the ARB extensions list. you can't claim it as functionality yet, cause it's practically limited to single vendor(especially when it's AMD, so it's probably broken by now or never actually worked. and there's like 1.5 people, who can\want to actually target AMD-hardware only), it's for tech-demos only. according to glview 4.08(i cannot download 4.11, problems with their ftp), it is only supported by HD 7900 and FirePro V, strange for a 2011-2012 extension.

you can't claim it as functionality yet, cause it's practically limited to single vendor

The thing is, as soon as a working extension exists, at least the chance exists that it's going to be promoted to core. It happend with AMD_debug_output. Why not this one? One could argue that through the existence of this extension, a suggestion for the next release has already been made - so I think aqnuep has a point.

especially when it's AMD, so it's probably broken by now or never actually worked.

no, you probably imagined yourself a bit different attitude. i said that because currently, they have very little resources assigned to opengl development. their bug-tracker and developer forums are half-abandoned. average driver bugs take about 6+ month to get addressed(and there's alot of those in queue), that is, if you lucky enough to get attention on their development forum. and it doesn't get better, cause opengl doesn't get much attention outside of embedded systems. and they are not even remotely as big corporation, as nvidia, so it looks like they don't have enough resources to have proper support for both opengl and directx, so they choose most popular one. there's like couple of volunteers currently actively working in opengl-division of AMD, Graham Sellers and couple of other guys.

The fact that AMD still don't have a full GL4.3 implementation doesn't inspire confidence. Don't get me wrong - I'm not knocking them - I'd love to see them come up with a full 4.3 implementation, with other cool new features, and made available where possible on older hardware too, but the hard reality is that they just haven't delivered.

I am more inclined to cut AMD a lot of slack nowadays, back in the day the when it was ATI, the OpenGL implementation was truly, truly horrendous, it was essentially just barely okay enough to play ID games... compared to then... AMD/ATI has come a really long way in a really good way since then... that GL4.3 is not there yet, but it is not that far off. G-truc has this matrix on his site: http://www.g-truc.net/doc/OpenGL%20matrix%202013-04.pdf ... according to that the following are all that are missing

GL_ARB_vertex_attrib_binding

GL_ARB_texture_view

GL_ARB_internalformat_query2

GL_ARB_framebuffer_no_attachments

GL_KHR_debug

GL_ARB_copy_image

the main thing missing that is a big issue (to me atleast) is GL_ARB_texture_view. I am not saying the others do not matter, but that one to me is the biggest deal.

I admit that I am more worried about bugs at this point, but far, far less worried than I was in the past.