download original
01:57 -!- multi_io [n=olaf@port-87-193-172-154.static.qsc.de] has joined ##OpenGL
03:55 < multi_io> is it possible to simultaneously (in a single frame) render more textures than fit into the
OpenGL implementation's (i.e., the GPU's) texture RAM?
03:56 < multi_io> (e.g. by creating new textures as necessary directly in the display() routine)
03:56 < _Auron_> I imagine that would be unforgivenly slow
03:58 -!- WolfDogDesigns [n=WolfDogD@cpc3-norw3-0-0-cust174.pete.cable.ntl.com] has quit ["Leaving"]
04:01 < multi_io> that depends, I guess
04:11 -!- bl4ckb1t_ [n=bl4ckb1t@unaffiliated/bl4ckb1t] has joined ##OpenGL
04:14 -!- reprore_ [n=reprore@ntkngw356150.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Read error: 54 (Connection
reset by peer)]
04:15 -!- CVirus [n=Satan@41.130.236.55] has left ##OpenGL ["I was somebody who, is no business of yours !"]
04:22 < RTFM_FTW> - VRAM is virtualized... so ultimately this is a meaningless question to ask...
04:22 < RTFM_FTW> - paging is completely transparent to the client
04:23 -!- bl4ckb1t [n=bl4ckb1t@unaffiliated/bl4ckb1t] has quit [Read error: 110 (Connection timed out)]
04:23 -!- bl4ckb1t_ is now known as bl4ckb1t
04:23 < RTFM_FTW> - you only have fairly indirect control over this (i.e. upload fewer / smaller textures etc.
in order to reduce paging)
04:27 -!- squi [i=Squishy@114-36-49-165.dynamic.hinet.net] has quit [" Ping Timeout"]
04:43 -!- GinoMan [n=quassel@c-76-124-139-231.hsd1.pa.comcast.net] has quit [Read error: 104 (Connection reset
by peer)]
04:50 -!- dv_ [n=dv@85-127-129-221.dynamic.xdsl-line.inode.at] has quit ["Verlassend"]
04:53 -!- Limoto_ [n=quassel@server.limoto.ifrit.eu] has quit [Client Quit]
04:53 -!- Limoto [n=quassel@server.limoto.ifrit.eu] has joined ##OpenGL
04:55 -!- BlueThen [n=bluethen@68-184-245-251.dhcp.stls.mo.charter.com] has quit []
04:58 < multi_io> RTFM_FTW: so you're saying that the GL implementation will also use the normal RAM to keep
textures?
04:58 < multi_io> is that what can be distinguished using glAreTexturesResident() ?
04:59 < multi_io> (i.e. resident = in VRAM)
05:04 < RTFM_FTW> - *what* the underlying GL implementation does (i.e. fallback to GART -> system memory or some
other storage) in these cases is completely implementation dependent
05:04 < RTFM_FTW> - and you have absolutely, positively zero control over (or knowledge of) this...
05:05 < multi_io> yeah, I understand that. I mean the common implementations I guess :-P e.g. the NVidia driver
under Linux, it looks like it does use system memory
05:05 < RTFM_FTW> - AreTexturesResident is a meaningless call anymore
05:05 < multi_io> ok
05:05 < RTFM_FTW> - its not going to tell you anything useful about this
05:05 < multi_io> this brings me back to my earlier question:
05:06 < RTFM_FTW> - and I've already answered that
05:07 < multi_io> 02:02 < multi_io> is it normal that a texture that you once succesfully created, bound,
applied and unbound, will no longer be available at a later time without you explicitly
removing it? So that if you later try to bind and apply it again, the primitive is just drawn
without the texture?
05:07 < multi_io> that one?
05:07 < multi_io> so I guess this should not happen?
05:08 < multi_io> ..rather, you would at some point no longer be able to create new textures without first
deleting some others?
05:08 < RTFM_FTW> - unbinding doesn't do *anything* to the underlying texture data... at least as far as the API
is concerned
05:09 < RTFM_FTW> - if you don't want it around *at all* then you need to delete it directly (via DeleteTextures)
05:09 < multi_io> yeah, ok
05:09 < RTFM_FTW> - anything beyond this falls into implementation dependent territory
05:09 < RTFM_FTW> - which you cannot concern yourself with
05:10 < multi_io> so, once I've succesfully created a texture, I should be able to bind/unbind it at any later
time
05:10 < multi_io> ...until I explicitly delete it
05:10 < RTFM_FTW> - whether or not a texture is paged out of < GART, local VRAM, ... > when unbound a completely
transparent process
05:10 < RTFM_FTW> - duh... the spec covers this BTW
05:10 < multi_io> I understand that, thanks :-P
05:11 < RTFM_FTW> - note my handle
05:11 < RTFM_FTW> - seriously A
05:11 < RTFM_FTW> - heheh
05:14 < multi_io> is the whole texture proxying stuff meaningless too?
05:15 < multi_io> (texture priorization)
05:15 < RTFM_FTW> - texture proxy != texture prioritization
05:15 < multi_io> ok, texture priorization I mean
05:15 < multi_io> *prioritization
05:19 < RTFM_FTW> - if you are looking for control over texture prioritization (i.e. user control over texture
purging for example) then you need to look at GL_APPLE_object_purgeable i.e.
http://developer.apple.com/graphicsimaging/opengl/extensions/apple_object_purgeability.html
05:19 < RTFM_FTW> - also GL_APPLE_client_storage, GL_APPLE_texture_range
05:19 < RTFM_FTW> - if you are looking for control over texture prioritization (i.e. user control over texture
purging for example) then you need to look at GL_APPLE_object_purgeable i.e.
http://developer.apple.com/graphicsimaging/opengl/extensions/apple_object_purgeability.html
05:19 < RTFM_FTW> - also GL_APPLE_client_storage, GL_APPLE_texture_range
05:20 < RTFM_FTW> - yes these are vendor specific (i.e. specific to Mac OS X) and no another equivalent "vendor
neutral" path (at least for the first extension) exists in GL
05:20 < RTFM_FTW> - http://www.opengl.org/registry/specs/APPLE/client_storage.txt
http://www.opengl.org/registry/specs/APPLE/texture_range.txt
05:20 < multi_io> nice
05:20 < RTFM_FTW> - quite
05:21 < multi_io> thanks
05:22 < RTFM_FTW> - what makes you think you need this level of control?
05:23 < RTFM_FTW> - beyond the fact that you aren't going to find it in Linux :P
05:23 < RTFM_FTW> - or Windows for that matter :P
05:24 < multi_io> I'm trying to do some medical (2D) imaging visualization here
05:24 < multi_io> with images getting very large, e.g. 10 MB or more
05:25 < multi_io> ...and many of them, 1000 for example
05:25 < RTFM_FTW> - manually implement a LRU cache on the client side
05:26 < multi_io> trying to display them in a kind of list control, with, in the worst case, something like 50
images visible at a time
05:26 < RTFM_FTW> - if you really want to do this in a vendor independent manner
05:26 < RTFM_FTW> - careful use of LOD will help you as well
05:27 < RTFM_FTW> - along with the usual suspects (i.e. non-FP data, texture compression, trimming components
etc. etc.)
05:27 < RTFM_FTW> - *trimming or packing components
05:29 < multi_io> I guess I wouldn't need the Apple extension, but the overview is an interesting read
05:30 < multi_io> answers some of my questions :-)
05:31 < RTFM_FTW> - well if you want to do this right APPLE_object_purgeable is a good path to take...
05:31 < RTFM_FTW> - along with all of the other approaches specified earlier
05:32 -!- firefly2442 [n=patrick@173-26-254-65.client.mchsi.com] has quit [Read error: 54 (Connection reset by
peer)]
05:35 -!- torchie [n=torchie@adsl-11-182-104.mia.bellsouth.net] has quit []
05:35 < multi_io> as to LRU caching -- I had written sth. like that already, but it does look like the nvidia
driver uses system RAM for texture storage, which suggests one should maybe use GL's
create/deleteTexture as the cache's backend
05:37 < RTFM_FTW> - this: "... but it does look like the nvidia driver uses system RAM for texture storage ... "
is implementation dependent ... the behavior you might have found here is not guaranteed
anywhere else... or even from ASIC to ASIC / driver to driver for the same vendor
05:37 < RTFM_FTW> - I'd suggest keeping this in mind
back to texturemapping
(C) 1998-2017 Olaf Klischat <olaf.klischat@gmail.com>