Perl 6 - the future is here, just unevenly distributed

IRC log for #pogl, 2017-01-20

| Channels | #pogl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
07:52 CandyAngel joined #pogl
19:35 chm joined #pogl
22:47 chm Mithaldu: re discussion of 2016-12-17 https://irclog.perlgeek.de/pogl/2016-12-17
22:48 chm Mithaldu: Could you please make some specific use cases for the performance issues you bring up?
22:48 chm That way I can be clear what is there, what is needed, and what is not.
22:49 Mithaldu chm: i already made some and told you about them last time ;)
22:49 Mithaldu sec
22:50 chm Mithaldu: What I need is real, working code, in
22:50 chm with Benchmark calls
22:50 chm or some such.
22:50 Mithaldu https://github.com/wchristian/OpenGL-Modern/blob/dev/lib/OpenGL/Modern/Helpers.pm#L304-L314
22:50 Mithaldu example 1 is glGetIntegerv_p
22:51 Mithaldu that is called at least once a frame in my stuff, the bufferdata one repeatedly
22:51 Mithaldu i'll benchmark that in 10 minutes and let you know of the exact diff
22:53 chm Ok, the GetIntegerv definitely needs the _p version for latency.
22:54 chm As mentioned in the referred to discussion, the OpenGL functionality would be preserved, i.e. the _p stuff.
22:54 chm However, if it can be made better/faster/simpler, I think we should do that as well.
22:55 Mithaldu well right now everything is _s, which is not great
22:55 Mithaldu otoh
22:55 chm Regarding the glBufferData, that is definitely getting fixed to use either a pointer to data or a pointer to a packed represenation or...
22:55 chm What is the problem with _s?
22:55 Mithaldu i am still working on figuring out which call versions scale well under which loads
22:56 Mithaldu if you have something that is already present in pointer form you must first stringify that before being able to do anything with it at the moment
22:56 chm The only difference between _s and _c is that _s works with SDL frames and PDL data
22:56 chm The _s only works with hand rolled c pointers
22:56 Mithaldu it's more philosophical
22:57 Mithaldu sometimes the thing i get the data from gives me a pointer
22:57 Mithaldu e.g. ALL of the image libraries
22:57 Mithaldu sometimes i may want to do it in a string if i'm doing some manipulation
22:57 chm In fact, the only difference between the OGA pointers and the SDL and PDL data is that SDL and PDL
22:57 Mithaldu you cannot usefully predict which it is
22:58 chm use a perl string for the memory management.  The data pointer is then equivalent to the string pointer
22:58 chm assuming you have (void *) rather than (char *)
22:59 chm Actually, since the mapping between a packed string representation and the
23:00 chm result of perl pack/unpack operations can be done, it is possible to roll your own perl data conversions.
23:00 chm My current thought is that for cases other than the _p varients, that the calls
23:00 Mithaldu i'm not sure where you're going with this
23:01 Mithaldu all i know is: i don't know yet which versions end up faster in a real world use
23:01 chm would expect the arguments to be a blessed reference.  That allows the existing _c , _s and _p (with OGA) which is actually _c
23:01 Mithaldu since the end speed is not just "how long does it take to call the call", but also "how long does it take to modify the data we're passing to it"
23:02 Mithaldu remember for example that PDL arrays are hilariously useless speed-wise as long as the logic of the changes per frame is contained in perl
23:02 chm ...to be used with the same interface.
23:03 chm Performance is definitely important for both OpenGL::Modern implementation and PDL::NextGen
23:03 Mithaldu also, please don't break your sentences at random places? it is VERY uncomfortable to read. just hit enter where you'd put a period or semicolon please?
23:04 chm May be out of your interest but I would like to improve the performance of PDL as far as latency goes.
23:04 Mithaldu there's one thing you can do
23:04 chm The line breaks are a result of poor typing skills and won't get much better.  Sorry.
23:04 Mithaldu but i am not entirely sure how much that would get you
23:04 Mithaldu the primary problem is:
23:05 Mithaldu every XS call has a base time cost you cannot skip
23:05 Mithaldu and at ~1µs it is *considerable*
23:06 chm So you're saying that even your current work with OGAs is less than you would like?
23:07 Mithaldu yes
23:07 Mithaldu right now i MUST regenerate the OGA every frame
23:07 Mithaldu as trying to read/write each relevant value in it for each frame is much slower due to the XS limit
23:07 chm Maybe there is a clever way we can do things.  Need to think about things.
23:08 Mithaldu just consider this example:
23:08 chm I'm going to have to head out in a moment.  I did just try editing the typemap file in OpenGL::Modern
23:08 Mithaldu you have 1000 sprites (e.g. image with position, size, texture, color)
23:09 chm to change the entry for 'const void* T_PV to be T_PTR and things seemd to build ok.
23:09 Mithaldu each frame you loop through all sprites, and generate for each property of each sprite a random +/- value, then add that to the existing values
23:09 Mithaldu (the randomness stands in for some perl logic)
23:09 chm You could try that to see if it improves things for you.  It should.
23:09 Mithaldu then you send that to the buffer function
23:09 chm I understand.
23:09 Mithaldu there's various ways to do that
23:10 Mithaldu but so far none are satisfying
23:10 Mithaldu regenerating the buffer each frame is so far the fastest
23:10 chm I hate to get too perl-version-specific but maybe we could use the token/op machinery to
23:10 Mithaldu can you push a commit of your edit to a temporary branch?
23:10 chm make an OP to do exactly a very low latency pack of data into a buffer.
23:11 Mithaldu i've played with custom ops already
23:11 Mithaldu seems to cut the XS time in half, but needs more playing around with
23:11 chm Sorry, that was all I had time for.  Will do so later but dinner now.  Cheers
23:11 chm o/
23:11 Mithaldu sure, push it and ping me over the night
23:11 Mithaldu i'll look at it in the morning
23:11 Mithaldu ciao o/
23:15 Mithaldu chm: benchmarks with classic and modern opengl: https://dl.dropboxusercontent.com/u/10190786/Microidium_bench_modern.rar
23:17 Mithaldu ah, i was mistaken about glgetinteger
23:18 Mithaldu that one's not called every frame
23:19 Mithaldu hmm, no idea which one i confused it for :/
23:21 Mithaldu glUniform4f_p went from 1µs to 4µs though, just to unpack that array
23:21 Mithaldu also
23:21 Mithaldu # spent 199ms making 31077 calls to Acme::MITHALDU::BleedingOpenGL::glBufferDataARB_p, avg 6µs/call
23:21 Mithaldu # spent 638ms making 31984 calls to OpenGL::Modern::Helpers::glBufferData_p, avg 20µs/call
23:31 Mithaldu chm: in summary, the big ones are these three: https://github.com/wchristian/OpenGL-Modern/blob/dev/lib/OpenGL/Modern/Helpers.pm#L312-L322
23:31 Mithaldu glbufferData because i can't just give it a pointer
23:31 Mithaldu and the glUniform ones because they will not accept arrays as input

| Channels | #pogl index | Today | | Search | Google Search | Plain-Text | summary