#jogamp @ irc.freenode.net - 20130316 05:05:59 (UTC)

20130316 05:05:59 -CatOut- Previous @ http://jogamp.org/log/irc/jogamp_20130315050645.html
20130316 05:05:59 -CatOut- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130316050559.html
20130316 05:14:19 * xranby (~xranby@anon) Quit (Ping timeout: 264 seconds)
20130316 05:16:06 * xranby (~xranby@anon) has joined #jogamp
20130316 05:16:27 * hharrison (~chatzilla@anon) has joined #jogamp
20130316 07:33:46 * hharrison (~chatzilla@anon) Quit (Ping timeout: 245 seconds)
20130316 11:32:46 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130316 18:04:05 * hharrison (~chatzilla@anon) has joined #jogamp
20130317 01:38:29 <hharrison> sgothel: curious what the need was for the new HashUtil stuff in gluegen
20130317 01:38:36 <hharrison> commit: 1a4514accc8f61ab7ff5fe8c82d22a5ef356c865
20130317 01:59:36 * odin_ (~Odin@anon) Quit (Remote host closed the connection)
20130317 02:39:15 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 252 seconds)
20130317 03:26:39 <sgothel> Doesn't the commit itself disclose it's reason ?
20130317 03:27:48 <sgothel> Long*HashMap was broken sort of, it's hash value of 1:1 was plain lacking distribution.
20130317 03:28:09 <sgothel> (* 1:1 cutting of the high 32bits that is :)
20130317 03:36:25 <hharrison> Sorry, I meant, what kind of input data is being hashed
20130317 03:36:37 <hharrison> ...or is at least anticipated to be hashed
20130317 03:37:29 <sgothel> good question .. at least now some generic pattern fast is being used w/ good distribution - answer: anything, native pointer / handles ..
20130317 03:37:58 <sgothel> http://home.comcast.net/~bretm/hash/7.html
20130317 03:38:27 <sgothel> Jenkins96 uses the same .. i.e. if you reduce it to 1 64bit input :)
20130317 03:39:49 <sgothel> I know .. special patterns for native pointers are being used sometimes cutting off lower bits etc, since this is generic, we cannot do that here
20130317 03:41:19 <hharrison> OK, I was mainly thinking along the lines of, are they aligned pointers or something we could play with low bits
20130317 03:42:38 <sgothel> -> MemoryObject and it's usage might need optimization
20130317 03:43:08 <sgothel> since we hashmap those aligned NIO chunks for GL memmap
20130317 03:44:26 <hharrison> I'm looking at some of the asm, on intel, a plain * 31 can actually do better in stead of the hash << 5 - hash
20130317 03:44:50 <hharrison> well, 32 bit anyway, mostly due to register pressure
20130317 03:45:02 <sgothel> // 31 * x == (x << 5) - x
20130317 03:45:29 <sgothel> hmm .. dunno
20130317 03:45:40 <hharrison> I know it's the same, I'm looking at what the jit does with it
20130317 03:45:47 <sgothel> i.e. we would need - right :)
20130317 03:46:56 <hharrison> I'm a C guy...I like to dump the asm from time to time.....for kicks ;-)
20130317 03:47:23 <sgothel> so 31*c would not involve the arithmetic unit ?
20130317 03:48:20 <hharrison> it would, but you can dual issue it with the next statement, hides the latency of mul, uses 2-3 fewer registers, which allows the inliner to avoid stack spills
20130317 03:48:43 <sgothel> -> expensive then - but I lack the buzzwords now why .. i.e. blocks the 'command stream'
20130317 03:49:07 <sgothel> so registers versus streaming
20130317 03:49:44 <sgothel> which brings me to the current OSX hacking .. have to 'stream' all CALAyer and window/view ops on main-thread (being off-thread of calling thread)
20130317 03:49:52 <hharrison> they still stream, you can issue a mul every cycle, it's when you go to use the result you stall
20130317 03:50:09 <sgothel> ah ..
20130317 03:50:09 <hharrison> but most ooo, machines hide that anyway
20130317 03:50:26 <sgothel> similar to my OSX hacking problem .. ugly API
20130317 03:51:17 <sgothel> see this - if you simply create a CALayer from a thread other than main-thread, the OSX GC may collect it very late ..
20130317 03:51:26 <hharrison> yeah, those CAlayer gymnastics I see in the jogl repo are.....interesting
20130317 03:51:40 <hharrison> read:terrifying
20130317 03:51:40 <sgothel> and it's not done yet .. horrible - have same for NEWT
20130317 03:52:37 <sgothel> well, CALayer should simply stream, since we don't really need those resources on another thread (I believe) - for NEWT this is quite different
20130317 03:53:17 <sgothel> and we cannot block main-thread -> deadlock w/ AWT-EDT and AWT-AppKit involved
20130317 03:54:07 <sgothel> whatever the 'other guys' come up w/ (Wayland .. X12 .. whatever) .. I hope it's thread safe :)
20130317 03:54:38 <hharrison> dmabuf == winning
20130317 03:55:04 <sgothel> yeah sure - it's an impl. detail, X11 is using this architecture for ages
20130317 03:55:24 <sgothel> i.e. a local pipe if possible -> dma mem mapped
20130317 03:56:33 <sgothel> sometimes I think the 'new kids' are overwhelmed by complexity, so they like to trash a working system to 'invent' a small 'solution'
20130317 03:56:46 <hharrison> nono, dmabuf
20130317 03:57:06 <sgothel> after the latter is around for some time, folks realize .. we have to add this and that .. then it gets bigger .. back to the cycle
20130317 03:57:07 <hharrison> it pushes the problem into the kernel, think of it like a fd for memory regions
20130317 03:57:28 <sgothel> thats is the old plain memmap
20130317 03:57:40 <sgothel> dmabuf is just an impl.
20130317 03:58:09 <hharrison> mmap has no concept of ownership by the hardware
20130317 03:58:16 <sgothel> I impl. memmap myself on DSPs for an own X11 driver and for video
20130317 03:58:19 <hharrison> That's the missing piece dmabuf brings
20130317 03:58:23 <sgothel> yes, memmap is an API :)
20130317 03:59:00 <sgothel> impl. via ioctl's .. old school - hopefully using hw accel
20130317 03:59:10 <sgothel> when sync memory etc
20130317 03:59:44 <sgothel> point here for drivers: it would be cool if all use the same backend, so they can share it hw-accel.
20130317 03:59:57 <sgothel> so a good technical impl. detail - sure
20130317 04:00:40 <sgothel> i.e. glMapBuffer would love those things .. but will end up to kernel ioctl's anyways
20130317 04:01:23 <sgothel> NVidia was just pissed not be allowed to use it :)
20130317 04:01:41 <hharrison> ahh, I see what you're getting at, yeah from an API perspective, it's just one more ioctl
20130317 04:02:20 <hharrison> (sorry I tend to get more intested by kernelspace the userspace when I'm nerding out)
20130317 04:03:02 <sgothel> it's just that I don't get the hype when folks talk like 'this is brand new', while that stuff is around since a very long time :)
20130317 04:03:19 <hharrison> Yeah, certiainly is a better way of doing buffer sharing between multiple GPUs
20130317 04:03:53 <hharrison> But apparently only opensource drivers get to play
20130317 04:04:09 <sgothel> and what I don't get is why an API to such things has license restrictions .. bad design
20130317 04:04:40 <hharrison> Nope
20130317 04:04:50 <hharrison> He who pays the piper calls the tunes
20130317 04:06:13 <hharrison> The ARM guys (linaro by way of TI) wanted to screw NV in the marjet
20130317 04:06:15 <hharrison> market
20130317 04:06:29 <hharrison> So, GPL only, sorry NV
20130317 04:06:30 <sgothel> hmm .. add modules to a system using basic features shouldn't be permissive? I don't care about NV here.
20130317 04:07:01 <hharrison> Hey, you want to link with kernel code, technically it all has to be GPL
20130317 04:07:04 <sgothel> more thinking about BSD etc - i.e. the whole driver space is now totally incompatible w/ BSD
20130317 04:07:27 <sgothel> one day Mesa/X11 was working on all platforms .. I remember :)
20130317 04:07:43 <sgothel> now .. Mesa's new stuff only works on Linux
20130317 04:08:07 <hharrison> Freebsd at least has Intel KMS now, and are sponsoring someone to do the ATI drivers (sorry, AMD)
20130317 04:08:26 <sgothel> duplicated work
20130317 04:08:42 <hharrison> No argument from me there
20130317 04:09:30 <sgothel> and I understand the anger of BSD folks, who cannot take back the GPL changes. Well, it's not perfect. Beauty from far ..
20130317 04:09:35 <hharrison> To be fair though, would we even have the current level of hardware documentation without linux driving openness
20130317 04:10:01 <hharrison> BSDs don't have nearly (if any) of the same leverage...also why they have the mindshare they do
20130317 04:10:08 <sgothel> BSD folks were 1st here .. but yes, GNU/Linux and BSD market share allowed the awesome 'openness'
20130317 04:10:23 <sgothel> On the server side they once had .. and they started it
20130317 04:10:47 <sgothel> You can talk w/ Theo (?) .. he is in Calgary I guess
20130317 04:11:02 <hharrison> Yeah, but the BSDs always piss me off with their technical purity wanks vs. actually shipping something that works....however poorly to start
20130317 04:11:27 <hharrison> It's not my fight really, I certainly empathise with the BSD guys
20130317 04:12:41 <hharrison> And if they really got their shit together, they have a huge opportunity if they just worked on being interchangable with linux in the android context
20130317 04:12:58 <sgothel> Another angle .. I think that writing drivers for hardware should always being payed by the vendor, while being open source to benefit widespread .. at least this thing is getting more and more acceptance.
20130317 04:13:07 <hharrison> Everything else there is already explicitly BSD, except the kernel
20130317 04:13:10 <sgothel> BSD -> GNU/Linux works, but not the other way
20130317 04:13:40 <hharrison> Yes, which is why they should work towards being the new kernel for manufacturers and they can ditch the one GPL component they have
20130317 04:14:23 <hharrison> I'm sure there's at least a few of those manufacturers that would throw devels back towards BSD if they could switch
20130317 04:14:34 <sgothel> :)
20130317 04:15:00 <hharrison> But I just don't see them having the mindset of being able to ship in that environment
20130317 04:15:32 <hharrison> Anyhoos, that was quite a digression ;-)
20130317 04:15:53 <sgothel> .. after all, yes - last 20 years gave free & open source a real boost and acceptance. Now science and universities need to open up (journals .. etc)
20130317 04:16:30 <sgothel> yup .. like that
20130317 04:18:32 <hharrison> You have a chance to look over that png patch yet?
20130317 04:18:48 <hharrison> I can have a run at it if not
20130317 04:19:02 <sgothel> nope .. I want a clean OSX now 1st. the easy stuff comes afterwards
20130317 04:19:13 <hharrison> Or if you have any other pending patches you'd like someone to triage, please ask
20130317 04:19:17 <sgothel> go ahead and test Julien's stuff ..
20130317 04:19:37 <sgothel> the patch itself looks ok (like Hernan's test code)
20130317 04:19:54 <sgothel> sure .. thx
20130317 04:20:08 <sgothel> if you like .. you can do the URL hash thing ..
20130317 04:20:11 <sgothel> etc etc
20130317 04:20:43 <sgothel> just pick what you like .. make comment in bug report, that you are working on it (assign yourself .. ) much appreciated
20130317 04:20:52 <hharrison> Yep, just trying to figure out where I can be useful with my somewhat sporadic time availability
20130317 04:20:58 <sgothel> then I don't know what Xerxes is doing w/ JOAL
20130317 04:21:39 <sgothel> you got email .. so openal-soft needs to be compiled on windows, best w/ our environment. plus the JavaSound removal
20130317 04:21:51 <hharrison> Right now with the team @work, I tend to merge 80-120 patches per week, which leaves me dead for much else
20130317 04:22:01 <sgothel> wow
20130317 04:22:30 <sgothel> hope they all have unit tests for functional validation, so you 'only' need to bitch about style :)
20130317 04:22:31 <hharrison> It sure is a firehose
20130317 04:23:23 <sgothel> eye of a needle - I would prefer a tree structure for that for better scaling of human resources
20130317 04:23:26 <hharrison> Nope, lots of design critique/functional review
20130317 04:23:57 <hharrison> There's a lot of peer review as well, but I tend to be on the lookout for painting ourselves into a corner
20130317 04:25:11 <sgothel> oha .. but you have unit tests. that is great, it always needs at least one w/ the big picture of everything, while some may be only highly specialized within their modules/world
20130317 04:25:39 <hharrison> Yeah, there's some pretty distinct modules that are effectively owned by experts
20130317 04:26:00 <hharrison> I tend to see when people could be using infrastructure we already have
20130317 04:26:16 <hharrison> Or see it go by twice and then go _build_ that infrastructure
20130317 04:26:19 <sgothel> .. and those discussion usually aligns style and philosophy .. so after a while, reviews always got more easier
20130317 04:26:29 <hharrison> yep
20130317 05:03:38 * hharrison (~chatzilla@anon) Quit (Ping timeout: 255 seconds)
20130317 05:06:12 -CatOut- Continue @ http://jogamp.org/log/irc/jogamp_20130317050612.html