download original
[08:39:13] *** multi_io has joined #lwjgl
[15:19:52] <multi_io> do the glTextImage* functions store the data (DataBuffer) pointer that you pass to them?
[15:20:17] <MatthiasM2> no
[15:21:10] <multi_io> so they copy the data to an internal buffer, and you can discard the passed buffer after the call?
[15:21:34] <MatthiasM2> the data is copied to an OpenGL texture
[15:22:25] <multi_io> I thought it uses the data buffer potentially whenever it needs the texture data again
[15:22:52] <multi_io> (unless it copied it to VRAM, but I thought that's implementation-specific)
[15:23:07] <MatthiasM2> www.opengl.org/sdk
[15:24:55] <multi_io> yeah, I read the glTextimagve2D manpage there, but it apparently doesn't explicitly say whether or not it copies the data
[15:25:48] <MatthiasM2> multi_io: it says what it does
[15:25:54] <MatthiasM2> you just have to read it
[15:27:24] <MatthiasM2> multi_io: compare the wording with glVertexPointer
[15:28:43] *** Diablo-D3 has quit IRC
[15:30:45] <multi_io> hm, ok
[15:32:40] <multi_io> so if you wanted to upload a setof textures into the GL to have them all available there to bind to, you'd preferably supply them in DataBuffers and then release the DataBuffer immediately afterwards if you wanted to save memory?
[15:33:01] <MatthiasM2> or use PBOs
[15:39:28] *** delt0r_ has quit IRC
[15:39:49] *** delt0r_ has joined #lwjgl
[15:48:21] * multi_io is reading http://www.songho.ca/opengl/gl_pbo.html
[15:50:37] *** HaBaLeS has joined #lwjgl
[15:55:17] <hanrock> multi_io as far as i know the image data that you supply to an opengl will be copied to some opengl managed memory and will be re-used from there whenever needed, you'll effectively end up having at least two copies of the same data, one in your programs memory managed by opengl and one in video memory
[15:55:53] <hanrock> though as to whether pbo methods do the same (copy data to opengl managed buffers) i unknown to me. i'd assume that to be the case. though someone knownledgeable about this could confirm this
[15:57:44] <hanrock> hmm but the dma.. maybe pbo methods rely on the buffer you supply as the last buffer before video ram.. then what happens if opengl references them when they have been freed - for example, when it needs to re-upload that texture to video ram?
[15:59:05] <MatthiasM> OpenGL is free to do what it wants with the memory behind PBOs
[15:59:21] <MatthiasM> so it could keep a reference to it as texture backing store
[15:59:22] *** Archon has quit IRC
[15:59:45] <MatthiasM> but for that you need to upload in a native texture format (eg not RGB)
[16:01:34] <hanrock> ABGR was it. at least that was directed as the "best" format for image data for speediest transfers by nvidia pdf
[16:01:50] <MatthiasM> or DXT1/3/5
[16:02:20] <hanrock> but but, if it's in native format and opengl keeps just a reference to the memory, lwjgl re-uses that memory buffer and then what? in the re-upload case the texture will be some random data?
[16:02:52] <MatthiasM> when you use PBO you have to map it, GL will decide what pointer to return
[16:03:19] <MatthiasM> that's why you should map it as write only
[16:03:46] <MatthiasM> so that GL doesn't have to provide valid data in that buffer
[16:06:33] <MatthiasM> hanrock: also LWJGL doesn't do anything - it's your app and OpenGL, LWJGL is just an wrapper
[16:07:16] <hanrock> i did something with nio buffers passed to it, re-using old buffers if they were not direct or something
[16:08:13] <hanrock> if they are direct all hell breaks loose when they dont get freed accordingly as you go happy about using new direct bytebuffers for texture data and discarding the old - and in the case opengl stores a reference to that direct bytebuffer, you cant re-use it for old textures.
[16:08:18] <hanrock> am i right?
[16:08:36] <MatthiasM> no
[16:08:40] <hanrock> explain please
[16:08:48] *** HaBaLeS has quit IRC
[16:08:53] <MatthiasM> I already did - read the links I gave to multi_io
[16:09:28] <hanrock> i rather stick to real people helping me
[16:09:48] <MatthiasM> hanrock: if you can't read then get lost
[16:09:50] <hanrock> sorry, not too intrigued to read the whole sdk without some pointers. not that your pointers are always all so helpful.
[16:10:14] <hanrock> can't. i'll wait for when you go to sleep and ask again.
[16:10:24] <MatthiasM> lol
[16:10:41] <MatthiasM> if multi_io was able to figure it out in a few minutes - why can't you?
[16:11:00] <hanrock> he's not looking for what i'm looking
[16:11:03] <hanrock> +for
[16:11:09] <MatthiasM> he was
[16:11:18] <hanrock> too bad. then we speak another language
[16:15:22] *** SleepwalkR has joined #lwjgl
[16:15:39] <MatthiasM> not sure what language you speak - but we used English here
[16:18:36] <kappaOne> hmm, got two methods that do the same thing, which would be faster/better to use?
[16:18:37] <kappaOne> http://lwjgl.pastebin.com/d7467d5b9
[16:19:08] <kappaOne> first create a varible to store result, second does the maths twice
[16:19:12] *** SleepwalkR has quit IRC
[16:19:13] <MatthiasM> kappaOne: doesn't matter
[16:19:21] <MatthiasM> use what looks nicer
[16:19:40] <kappaOne> that'll be the second then :)
[16:20:54] <MatthiasM> but I would use if timeStep < 1
[16:21:14] <kappaOne> ah, nice, didn't think of that
----
01:53 < multi_io_> MatthiasM2: I can now definitely say that it is the native glTexSubImage2D function call that takes 100 ms.
01:53 < multi_io_> i.e. no Java code
01:53 < NoobFukaire> what kind of data?
01:53 < MatthiasM2> what texture format?
01:54 < NoobFukaire> PNG is much slower than DXT1 for example
01:54 < MatthiasM2> NoobFukaire: this has nothing to do with PNG
01:54 < MatthiasM2> as nthe decoding is already done before the upload
01:54 < NoobFukaire> You could load via PBO, which won't fix the performance itself but will make it less noticable
01:54 < NoobFukaire> yeah but with PNG mipmaps have to be generated (possibly)
01:55 < NoobFukaire> also I didn't mean the PNG loading from disk takes long
01:55 < MatthiasM2> ok, that can be the case if you use GL_GENERATE_MIPMAPS
01:55 < NoobFukaire> also PNG are generally going to be larger than compressed textures
01:56 < MatthiasM2> let's just say DXT compressed textures vs uncompressed textures :)
01:57 < multi_io_> I'm using a library to create the texture from a BufferedImage. I'll have to look at what parameters
are actually passed down to the native call
01:57 < NoobFukaire> Java's image stuff sucks
01:57 < NoobFukaire> it's feature rich but slow as fuck
01:59 < MatthiasM2> multi_io_: use the PNGDecoder from TWL
01:59 < MatthiasM2> it can decode into a native format for OpenGL
01:59 < MatthiasM2> so you don't have to copy the data several times
02:00 < NoobFukaire> MatthiasM's PNG loader is great
02:00 < MatthiasM2> it got 8bit palette support recently too
02:01 -!- Gwinnell [n=Ashley@cpc1-pool2-0-0-cust61.sotn.cable.ntl.com] has quit [Read error: 110 (Connection timed out)]
02:06 < multi_io_> hm
02:08 < MatthiasM2> multi_io_: anyway don't send data as GL_RGB
02:08 < multi_io_> problem is, the source data is DICOM (medical image format), and I have a library that reads that into
BufferedImages.
02:09 < MatthiasM2> then be sure to convert it into GL_ABGR
02:10 < multi_io_> ok
02:14 -!- Sajber^ [n=Sajber@h-142-12.A213.priv.bahnhof.se] has quit [Read error: 104 (Connection reset by peer)]
02:19 < multi_io_> the parameters that the library passes down to the native glTexSubImage2D call are:
target=GL_TEXTURE_2D, level=0, xoffset=yoffset=0, width=819, height=999, format=GL_LUMINANCE,
type=GL_UNSIGNED_BYTE
02:19 < MatthiasM2> urgs - the size is an issue
02:19 < MatthiasM2> try to align the linesize to a multiple of say 32 byte
02:19 < multi_io_> GL_LUMINANCE kind of makes sense; the ingoing BufferedImage is a 16-bit grayscale one
02:20 < MatthiasM2> and use GL_TEXTURE_RECTANGLE
02:20 < multi_io_> "linesize"=width?
02:21 < multi_io_> width/8
02:21 < MatthiasM2> not directly: stride == width * bytesPerPixel
02:21 < NoobFukaire> is this some kind of image viewer or are you streaming data to the gpu every frame?
02:22 < MatthiasM2> and that should be a multiple of at least 4 bytes
02:24 < multi_io_> NoobFukaire: yes it's gonna be an image viewer, displaying maybe 25 images at a time out of 2000 (all
of the size of the one above)
02:25 < multi_io_> I can't reasonably load all those textures up-front I think
02:25 < NoobFukaire> k, you're probably going to want to do the texture upload with PBO and then the texture submission
calls will be very cheap from PBO -> texture
02:26 < multi_io_> so right now I'm loading the textures into GL when they're being displayed the first time, so the
display() methods is delayed by those 100 ms (times the number of new textures to be displayed)
02:26 < NoobFukaire> with PBO you can be uploading in a different thread
02:27 < NoobFukaire> and then you just need to notify your display code about upload state (i.e. loading bar or whatever)
02:27 < multi_io_> yeah I was thinking of something like that, I'm afraid of triggering dozens of driver bugs when calling
GL from multiple threads :P
02:28 < NoobFukaire> mapped buffers are safe, it's like the only reliable way to do asynchronous stuff with GL
02:50 < multi_io_> so I would then basically use the same GL context (and, in it, the same PBOs) from multiple threads,
right?
02:51 < multi_io_> and use Java synchronization to ensure that I won't do things like initializing a PBO in one thread and
at the same time already drawing it in another thread
02:52 < NoobFukaire> well, you map the buffer to client memory from the GL thread
02:52 < NoobFukaire> then you hand it off to your IO thread which can copy the data independently
02:53 < NoobFukaire> then when that thread is finished, you'd do like you said, with some kind of synchronized
notification system to tell GL thread it's okay to unmap the buffer and use it in the GL thread
02:53 < NoobFukaire> the PBO creation is all still done in the GL thread
02:57 < MatthiasM2> multi_io_: GL stays single threaded, you only pass a ByteBuffer to the other thread - use
java.util.concurrent queues for that
02:53 < multi_io_> RTFM_FTW: the glTexSubImage2D call that takes 100 ms is called with: target=GL_TEXTURE_2D, level=0,
xoffset=yoffset=0, width=819, height=999, format=GL_LUMINANCE, type=GL_UNSIGNED_BYTE
02:53 -!- Lemml [n=andreas@pD9E52D16.dip.t-dialin.net] has joined ##OpenGL
02:54 < multi_io_> is that a "native" format/type combination?
02:55 < RTFM_FTW> - LUMINANCE should be native but I'm wondering WTF are you attempting to SubImage with < 819, 999 > NPOT
dimensions...
02:56 < RTFM_FTW> that is just nasty...
02:56 < RTFM_FTW> - heh
02:57 -!- gonsor [n=quassel@p57A8AA7D.dip0.t-ipconnect.de] has quit [Read error: 110 (Connection timed out)]
02:57 < multi_io_> the people in #lwgl were asking that too :P
02:57 < RTFM_FTW> - and the answer would be?
02:58 < multi_io_> it's a medical image viewer; those are the dimensions of the image... the glTexSubImage2D call is done
by a library which I use to read those images into GL
02:58 < NoobFukaire> you can pad the texture to ^2 and "fix" things with texture coordinates
03:00 < RTFM_FTW> - yup
03:01 < RTFM_FTW> - in this case I'd definitely recommend padding the data
03:02 < multi_io_> ok, I understand
back to pbos
(C) 1998-2017 Olaf Klischat <olaf.klischat@gmail.com>