PDA

View Full Version : Tiled Resources like a better version of tiled resources in DirectX 11.2



Gedolo
06-29-2013, 12:51 PM
DirectX11.2 has an interesting feature,
it's called tiled resources

Massive Virtual Textures for Games: Direct3D Tiled Resources
http://channel9.msdn.com/Events/Build/2013/4-063

http://hothardware.com/News/Microsoft-Rolls-Out-DirectX-112-But-Its-A-Windows-81-Exclusive/ (http://channel9.msdn.com/Events/Build/2013/3-062)

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/microsoft-directx-112-brengt-meer-detail-naar-games-dankzij-tiled-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.

aqnuep
06-29-2013, 02:05 PM
There is already an extension for that, which is even more powerful than DX11.2 tiled resources (see AMD_sparse_texture (http://www.opengl.org/registry/specs/AMD/sparse_texture.txt)), in fact, pretty much this time DX "borrowed" from GL, like they did with most of their DX11.1 features.

Nowhere-01
06-30-2013, 12:20 AM
There is already an extension for that, which is even more powerful than DX11.2 tiled resources (see AMD_sparse_texture (http://www.opengl.org/registry/specs/AMD/sparse_texture.txt)), 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.

P.S. there's high chance i'm talking bullshit, cause i'm not very up-to-date with latest extensions, i don't need those yet. andi'm not sure, how exactly ARB works.

thokra
07-02-2013, 04:29 AM
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.

That might be interpreted as BS... ;)

Nowhere-01
07-02-2013, 05:16 AM
That might be interpreted as BS... ;)

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.

thokra
07-02-2013, 05:38 AM
you probably imagined yourself a bit different attitude

Yes, I tend to be optimistic and I like to put faith in the few people actually invested in OpenGL development. I'm sure they're doing their best.

mhagain
07-02-2013, 08:08 AM
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.

kRogue
07-02-2013, 05:14 PM
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.