JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20150304 05:05:35 (UTC)

20150304 05:05:35 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150303050535.html
20150304 05:05:35 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150304050535.html
20150304 08:06:32 * monsieur_max (~maxime@anon) has joined #jogamp
20150304 08:10:43 * doev (~doev@anon) has joined #jogamp
20150304 08:37:29 * eclesia (~husky@anon) has joined #jogamp
20150304 08:37:34 <eclesia> good morning
20150304 12:17:58 <eclesia> question on Vulkan : is it a replacement for opengl ? or an api for a different purpose ?
20150304 12:24:26 <rmk0> .o.
20150304 12:24:34 <rmk0> eclesia: replacement
20150304 12:24:41 <eclesia> rmk0: hi
20150304 12:24:45 <rmk0> lo
20150304 12:24:53 <eclesia> so OpenGL 4.5 is the last one
20150304 12:25:14 <rmk0> don't know
20150304 12:25:28 <rmk0> imagine interest in opengl will vanish when all the drivers get support for vulkan
20150304 12:25:40 <rmk0> they claim vulkan can work on any gpu supporting opengl es 3.1 and up
20150304 12:26:27 <monsieur_max> still got a few years before seeing that everywhere no ? what do you think ?
20150304 12:26:34 <rmk0> most likely
20150304 12:26:55 <rmk0> don't even have a specification yet
20150304 12:27:21 <rmk0> i'm guessing it'll look like opengl + bindless + direct state access
20150304 12:29:21 <rmk0> no more state machine \o/
20150304 12:29:21 <xranby> eclesia: rmk0: the best explenation i have seen is in http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus
20150304 12:29:26 <xranby> with example code snippet
20150304 12:29:57 <xranby> vkCmdBindDescriptorSet(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, textureDescriptorSet[0], 0);
20150304 12:30:04 <xranby> vkQueueSubmit(graphicsQueue, 1, &cmdBuffer, 0, 0, fence);
20150304 12:30:10 <xranby> vkMapMemory(staticUniformBufferMemory, 0, (void **)&data);
20150304 12:30:17 <xranby> // ...
20150304 12:30:23 <xranby> vkUnmapMemory(staticUniformBufferMemory);
20150304 12:30:55 <xranby> so in a nutshell there is no uniforms in vulkan instead you need to use these special memory map functions
20150304 12:31:51 <xranby> writing to GPU memory is the only way to pass data to shaders.
20150304 12:32:52 <eclesia> looks like there are no 'stages' anymore. (vertex,tesselation,fragement) ...
20150304 12:33:18 <eclesia> no stencils, depth buffer etc...
20150304 12:33:34 <xranby> a big bonus is that you can update the GPU memory using many parallel threads
20150304 12:35:52 <xranby> eclesia: yes "A consistent idiom in Vulkan is to have the first parameter to all entry points be the representation of the state that you are going to change with the function call."
20150304 12:36:31 <xranby> the bind statemachine is out the window \o/
20150304 12:36:42 <zubzub> it's almost as if they are aiming to some kind of object oriented approach in C
20150304 12:36:51 <zubzub> :p
20150304 12:37:06 <zubzub> where the first paramater is the object you're operating on
20150304 12:38:56 <eclesia> I guess I'll split out the 3d model api outside opengl to be ready for other rendering methods
20150304 12:39:08 <xranby> zubzub: the core idea is to have the API stateless -> enable multithreading
20150304 12:42:33 <zubzub> so the api doesn't modify anything that you pass it
20150304 12:42:44 <zubzub> and if it does, it returns a fresh copy?
20150304 12:45:16 <xranby> zubzub: that would be Immutable objects nope vulkan is very much mutable
20150304 12:45:52 <xranby> zubzub: vulkan puts the responsibility to manage the mutable data (GPU memory) by the application instead of the gpu driver
20150304 12:46:50 <zubzub> oh ok ic
20150304 12:47:23 <xranby> zubzub: vulkan remove use of bind so that the API is stateless when it comes to decide which data to modify, this bind-less stateless API allows the application to use many threads to alter the GPU memory
20150304 12:48:28 <zubzub> excellent0s
20150304 12:55:28 <xranby> zubzub: of course, you may create a 3dengine that uses immutable objects on top of vulcan, and as long as you use your own 3dengines API you have an inherently thread-safe GPU API
20150304 12:56:44 <xranby> i am sure rmk0 have susch an API
20150304 12:58:24 <eclesia> haha it still has 'stages' called EntryPoints
20150304 12:59:06 <eclesia> so in fact Vulcan is a GL4.5 in binary form and different memory management
20150304 13:00:32 * eclesia is reading spir-v spec
20150304 13:01:25 <eclesia> just one new stage : GLCompute after the fragment shader.
20150304 13:04:28 <eclesia> bytecode isn't very complicate
20150304 13:05:11 <xranby> spir-v spec https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html and whitepaper https://www.khronos.org/registry/spir-v/papers/WhitePaper.html
20150304 13:05:28 <eclesia> xranby: op I'm on it ^^
20150304 13:13:26 <rmk0> i'd rewrite my renderer for vulkan
20150304 13:17:44 <eclesia> rmk0: umbrella ?
20150304 13:26:41 <eclesia> rmk0: parasol = opengl , umbrella = spir-v :D
20150304 13:29:27 <rmk0> eclesia: parasol is the shading language, which only exists because glsl is awful
20150304 13:29:51 <rmk0> i'd also rewrite it unless there was a decent shading language
20150304 13:29:57 <rmk0> would output spir-v
20150304 13:35:41 <rmk0> i'd hope that the existence of spir-v would make it viable for new platform-independent shading languages
20150304 13:35:45 <rmk0> and then i'd not have to write one
20150304 13:42:20 <rmk0> right now anyone writing a language has to output glsl
20150304 13:42:28 <rmk0> so everyone just writes glsl by hand
20150304 13:54:14 <rmk0> i assume vulkan won't declare a dependency on any language in particular, and will expect people to submit spir-v bytecode
20150304 13:54:50 <rmk0> no more glsl \o/
20150304 13:58:26 <rmk0> ... anyone else not particularly impressed by that powervr demo?
20150304 13:58:55 <rmk0> i'll be more impressed if that turns out to be real-time GI, but i don't think it is
20150304 14:01:04 <monsieur_max> related : http://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl
20150304 14:26:42 <sgothel> maybe we can start a new sub-thread in forum / and a bug report for Vulcan ..
20150304 14:27:02 <sgothel> i.e. how to adopt it .. as an alternative parallel to our GL/GLContext ?
20150304 14:27:23 <sgothel> glsl is the 1st class citizen frontend .. offline compiler
20150304 14:27:49 <sgothel> so we would need to add spir-v IR somewhat .. support, maybe
20150304 14:28:14 <sgothel> Vulcan command queue =? GL context ?
20150304 14:28:26 <sgothel> i.e. Vulcan Command queue is a bit like OpenCL ofc :)
20150304 14:29:17 <sgothel> so maybe .. the binding design (JOGL/JOCL) shall have a common subset
20150304 14:31:44 <sgothel> if khronos makes their spir-v front end free software, then better ..
20150304 14:33:39 <sgothel> *Vulkan* :)
20150304 14:41:41 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1137 Add Support for Vulkan
20150304 14:44:17 <sgothel> when headers (free software license) are available, pls post reference here :)
20150304 14:45:16 <sgothel> probably we can have OpenCL >= 2.1 / Vulkan command queue/buffer common subset
20150304 14:50:57 <sgothel> https://jogamp.org/bugzilla/showdependencytree.cgi?id=1137&hide_resolved=1
20150304 14:51:47 <sgothel> please add yourself to the bug entries, so we can record our discussion / discussion-results there, thx!
20150304 14:53:16 <sgothel> .. added the 'usual suspects' :)
20150304 14:55:05 <eclesia> sgothel: will need a class to manage real cpu memory, to share data with it
20150304 14:55:23 <eclesia> something different from vbo
20150304 14:55:34 <sgothel> yes, we have that already in JOGL .. and similar in JOCL
20150304 14:55:47 <sgothel> in JOGL we even track the memory buffers
20150304 14:56:00 <sgothel> (states)
20150304 14:56:23 <sgothel> most low-level basics can be reused
20150304 14:57:01 <sgothel> I just like to generalize our current high-level stuff, i.e. GLContext, GLDrawable, GLAutoDrawable
20150304 14:57:09 <sgothel> so it can be used by either GL or Vulkan
20150304 15:22:40 <sgothel> so that will bump JOGL to 3.0 then I guess, Mark? :)
20150304 15:23:40 <sgothel> (he would like to split the whole probably in thousand little projects we would need to put in a build/test web matrix .. :)
20150304 15:25:03 <sgothel> @Mark: Maybe you like to lead the spir-v thingy, e.g. w/ front ends (glsl, your shader language, ..)?
20150304 15:25:37 <rmk0> hello
20150304 15:25:46 <rmk0> er
20150304 15:27:16 <rmk0> well basically: i hope other projects will build usable shading languages that output spir-v; i think this is almost inevitable because vulkan won't define one and therefore someone's going to have to write *something* in order to do anything. if the languages other people write turn out to be horrible (and they almost inevitably will, because all they'll try to do is reinvent glsl), i'll be writing my own
20150304 15:27:24 <sgothel> "thousand little projects", b/c while I have not seen the API yet, I can see how many common things they have .. i.e. Vulkan = OpenCL stuff + a bit of graphics :)
20150304 15:27:45 <rmk0> it won't be parasol, because so much of the design of parasol was limited by having to support a specific subset of glsl
20150304 15:27:53 <rmk0> parasol is obsolete!
20150304 15:29:09 <rmk0> all of this is completely hypothetical because i can't even work with vulkan until it has good support on FOSS drivers
20150304 15:29:21 <sgothel> I was like: nice to have (antlr?) syntax parser, spir-v introspection lib, compiler to output spir-v, and/or a native binding to a khronos spir-v tool .. ,
20150304 15:29:23 <rmk0> and they've not even released a specification yet, so that's likely a year or two away
20150304 15:29:34 <sgothel> yes .. just brainstorming
20150304 15:29:42 <rmk0> parsing spir-v seems pretty easy
20150304 15:29:51 <sgothel> IMHO the spir-v introspection thingy .. might be useful and needed
20150304 15:30:18 <sgothel> i.e. vars/functions and the like .. to be hooked to application
20150304 15:30:38 <sgothel> AFAIK spir-v API is available already
20150304 15:31:05 <sgothel> yes .. an 'end of this year' thingy :)
20150304 15:32:11 * eclesia has AST for GLSL, could make in a few hours a spir-v bytecode reader/writer
20150304 15:33:38 <sgothel> great, using a stream .. e.g. our Bitstream class in GlueGen
20150304 15:33:49 <sgothel> I assume we can 'take' that (license)
20150304 15:34:06 <sgothel> (while you don't like to push to our repos .. oh well :)
20150304 15:34:17 <eclesia> :D
20150304 15:38:39 <xranby> hi, if we want a list of unofficial vulkan api names then take the AMD mantle api and replace the gr prefix with vk prefix
20150304 15:38:52 <rmk0> heh
20150304 15:39:30 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1140
20150304 15:39:59 <sgothel> @Xerxes: yes I was thinking about that .. :)
20150304 15:40:18 <sgothel> at least I can test GlueGen .. hmm
20150304 15:40:28 <sgothel> mantle api headers ?
20150304 15:40:40 <xranby> you can get a good list of Vulkan resources by searching for vkMapMemory
20150304 15:40:57 <sgothel> Bug 1140: SPIR-V stuff .. @Mark, @Eclesia .. pls coordinate and take over, thank you! :)
20150304 15:41:28 <sgothel> oh dear .. everything so 'secret' :)
20150304 15:42:12 <rmk0> i don't think anyone here is going to write a glsl compiler
20150304 15:42:12 <xranby> sgothel: mantle api headers, let me check... searching for grMapMemory
20150304 15:42:40 <eclesia> I couldn't find any spir-v bytecode files so far, so if anyone have links, that would be appreciated :)
20150304 15:42:43 <sgothel> (just saying .. Khronos could do all this a bit more public)
20150304 15:43:05 <sgothel> http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus <- a little here
20150304 15:43:55 <sgothel> https://stackoverflow.com/questions/20966317/does-amd-mantle-api-already-available
20150304 15:44:19 <eclesia> thks
20150304 15:44:43 <sgothel> no bytecode .. just 'public' browsing
20150304 15:46:56 <sgothel> http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/mantle#downloads
20150304 15:48:25 <sgothel> "As of July 2014, the Mantle specification and development materials remain unavailable to the general public, even less declared an open standard."
20150304 15:48:52 <sgothel> http://vulkan-tutorial.com/
20150304 15:52:04 <sgothel> http://community.amd.com/community/amd-blogs/amd-gaming/blog/2015/03/02/on-apis-and-the-future-of-mantle <- March 5th GDC 2015
20150304 15:56:09 <xranby> no headers then :/
20150304 15:56:19 <xranby> the dumps from the amd dll and the Imagination Technologies code snippet confirm API similaritys that grCmdBindDescriptorSet -> vkCmdBindDescriptorSet grQueueSubmit -> vkQueueSubmit grMapMemory -> vkMapMemory grUnmapMemory -> vkUnmapMemory
20150304 15:56:30 <sgothel> not yet, same goes for https://www.khronos.org/registry/spir-v/ - PDF at least ..
20150304 15:56:50 <sgothel> and hence .. it is _very_ similar to OpenCL low-level ..
20150304 15:57:05 <sgothel> good
20150304 15:57:25 <sgothel> lets hope the 'kernel' setup is easier :)
20150304 15:57:44 <xranby> http://vulkan-tutorial.com/debugger.png <- this picture from valve confirm a lot of function names and parameters!
20150304 15:58:06 <rmk0> hehe
20150304 15:59:00 <xranby> the picture is the dota 2 game by the way
20150304 15:59:23 <xranby> here using vulkan
20150304 16:00:49 <xranby> (its part of the bridge seen at the centre of the dota 2 map http://i.imgur.com/zcDcNrA.jpg )
20150304 16:01:54 <xranby> err.. not bridge but stones that slope into the water
20150304 16:02:05 <sgothel> guess we have the new API in our architectural mindset now .. ready for things to come :)
20150304 16:52:41 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150304 17:07:11 * eclesia (~husky@anon) has left #jogamp
20150304 17:21:32 * doev (~doev@anon) Quit (Ping timeout: 245 seconds)
20150304 17:26:08 * mbien (~mbien@anon) has joined #jogamp
20150304 17:35:18 <xranby> mbien: hello and welcome, still working on opencl?
20150304 17:36:21 <mbien> oh hello. this thing is on hehe
20150304 17:36:33 <mbien> yeah sometimes i still do things with cl
20150304 17:37:03 <xranby> mbien: have you explored the options to use opencl on mobile devices using jogl?
20150304 17:37:42 <xranby> a lot of work have been put into jogamp to enable jocl to work on mobile devices since device drivers have emerged
20150304 17:37:52 <mbien> i played with cl on mobile years ago. bot not in a project. no
20150304 17:38:52 <mbien> i forgot the company name but we got devkits of some test hardware back then
20150304 17:39:11 <mbien> but i didn't do anything with android recently
20150304 17:41:31 <mbien> nice to see jogamp still going
20150304 17:42:05 <mbien> booted an old os and had this channel on autojoin
20150304 17:44:25 * kg0909 (0e8b5206@anon) has joined #jogamp
20150304 17:46:33 <kg0909> Hello i i am having trouble in installing jogl. When i do ant in the make directory, i get the following log https://gist.github.com/kartikgupta0909/144625ca1c1164e83a87
20150304 17:46:38 <xranby> mbien: yes its on! using gpgpu and hw accelerated resources is escalating especially in the embedded field, i jumped on the jogamp project when i realised the bottlenects trying to use CPU only to do tasks on embedded systems
20150304 17:47:40 <xranby> kg0909: hi are you able to use the jogamp provided builds of jogl or do you have to build it yourself?
20150304 17:48:03 <xranby> kg0909: you need to have a compiled gluegen build next to jogl
20150304 17:48:12 <xranby> fot the jogl build scripts to work
20150304 17:48:40 <kg0909> xranby, i have no such restrictions. I juts want to install jogl and gluegen in the latest versions
20150304 17:48:53 <kg0909> xranby oh okay, i need to compile gluegen first?
20150304 17:49:21 <xranby> http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z <- this file contains both jogl and gluegen compiled for all the architectures that jogamp support
20150304 17:49:42 * monsieur_max (~maxime@anon) has joined #jogamp
20150304 17:49:47 <xranby> kg0909: i would recommend you to try use this archive first and see if it work for you
20150304 17:51:11 <xranby> if you want to build it yourself then try the build instructions at: http://jogamp.org/jogl/doc/HowToBuild.html
20150304 17:53:07 <xranby> yes you need to build gluegen first
20150304 17:53:30 <xranby> Build the source tree:
20150304 17:53:30 <xranby> Open a command shell in the "gluegen/make" directory of the source tree and type "ant".
20150304 17:53:30 <xranby> Then open a command shell in the "jogl/make" directory of the source tree and type "ant".
20150304 18:16:57 <kg0909> xranby : It worked
20150304 18:17:30 <kg0909> xranby I think this point should be explicitly mentioned on the guidelines page. It would be helpfull
20150304 18:18:42 <kg0909> if you want i can do that
20150304 18:18:58 <kg0909> i like to contribute
20150304 18:22:33 * Eclesia (~eclesia@anon) has joined #jogamp
20150304 18:29:05 <Eclesia> okay, time to start playing with spir bytecode ^^
20150304 19:02:27 <Eclesia> :( couldn't find any bytecode in spir-v
20150304 20:14:35 * xranby_GTX580 (~familjen@anon) has joined #jogamp
20150304 20:18:16 <Eclesia> xranby_GTX580: Are you mocking us with your big gtx580 :p
20150304 20:19:09 <xranby_GTX580> its the only impressive part of this machine, the cpu is an intel d ;)
20150304 20:20:26 <Eclesia> big muscle but no brain :D
20150304 20:20:56 <xranby_GTX580> so... yes... thats why gpgpu is important
20150304 20:22:16 <Eclesia> GPU core will evolve until they reach ARM
20150304 20:23:05 <Eclesia> SPIR-V : all constants listed ... pfiu that's long
20150304 20:25:17 <Eclesia> for those interested : https://bitbucket.org/Eclesia/unlicense/src/920d3ad1fbb469fe15a1cd1c4dfee936fcd1c9cb/compiler/compiler-spir/src/main/java/un/language/spir/SpirConstants.java?at=default
20150304 20:25:37 <Eclesia> constants look much like what we find in opengl
20150304 20:25:52 <Eclesia> nothing really new here :/
20150304 20:28:18 <rmk0> well it's not like current GPUs have a different shading model than what's exposed in opengl
20150304 20:29:25 <rmk0> interesting that INPUT_QUADS exists...
20150304 20:29:43 <Eclesia> I believe it's for backward compatibility
20150304 20:30:00 * kg0909 (0e8b5206@anon) Quit (Quit: Page closed)
20150304 20:31:34 * rmk0 stamps on history
20150304 20:37:05 * Eclesia starts to believe it could be possible to transform javabytecode (with proper model) to spir-v
20150304 20:38:17 <rmk0> a subset of it, almost certainly
20150304 20:38:27 <rmk0> i don't think gpus have stacks
20150304 20:38:33 <rmk0> no recursion
20150304 20:39:18 <Eclesia> sure sure, but why create a new syntax, we could just reuse the one we know best in are favorite IDE. ^^
20150304 20:39:53 <rmk0> i take the opposite approach in all things
20150304 20:42:46 <Eclesia> nice thing : ops have defined length, so we can skip unknown ones ^^ nice
20150304 21:40:02 <Eclesia> sgothel: spir-v reader and writer done XD
20150304 21:40:06 <Eclesia> https://bitbucket.org/Eclesia/unlicense/src/tip/compiler/compiler-spir/src/main/java/un/language/spir/?at=default
20150304 21:40:51 <Eclesia> missing the opcode bank but even in this state it's usable.
20150304 21:41:05 <Eclesia> no tests since I couldn't find any file :/
20150304 21:54:10 <sgothel> great stuff .. thank you!
20150304 21:54:34 <sgothel> I guess I will 'steal' this in a while :) - having your permission
20150304 21:55:24 <sgothel> your const: int -> byte maybe?
20150304 21:55:41 <sgothel> SpirConstants ..
20150304 21:56:21 <sgothel> thx! https://jogamp.org/bugzilla/show_bug.cgi?id=1140#c2
20150304 21:56:53 <sgothel> @mbien: welcome back!
20150304 21:57:20 <mbien> hello sven :) how is going?
20150304 21:58:04 <sgothel> great, thank you. we got a son http://jausoft.com/photos/2015/20150199-SvensonHan/
20150304 21:58:11 <sgothel> .. and the usual coding fun :)
20150304 21:58:26 <mbien> wow congrats man!
20150304 21:59:21 <sgothel> I (and a few ..) were searching for you [in the internet] .. couldn't find anything, we already got the worst ideas - so good to 'see' you are alive!
20150304 22:00:06 <sgothel> hope all is great
20150304 22:00:34 <mbien> oh lol. nah. i just shutdown my server with the blog. drop me a mail next time before getting bad ideas
20150304 22:00:47 <mbien> all fine on my side
20150304 22:00:52 <Eclesia> ?
20150304 22:01:16 <xranby_GTX580> http://www.g-truc.net/post-0714.html#menu 03/03/2015 Redefining the shading languages ecosystem with SPIR-V
20150304 22:01:47 <sgothel> good to know!
20150304 22:02:16 <mbien> the domain ran out (forgot about that) then i was just to lazy to set it up again. so i left it this way
20150304 22:02:30 <sgothel> @Eclesia: mbien was here since the beginning of JogAmp .. JOCL is his 'baby' .. and so on ..
20150304 22:03:05 <sgothel> @xerxes: thx - collecting all the links .. :)
20150304 22:03:19 <Eclesia> :o another Dark God of Jogamp hidden in the shadows :)
20150304 22:03:35 <sgothel> thinking about setting up a wiki for us: 'Vulkan, OpenCL, SPIR-V, .. in Harmony'
20150304 22:03:37 <Eclesia> mbien: welcome then, I'm just a random newbie here ^^
20150304 22:04:59 <mbien> thanks. i am only lurking here ;) was going through the vulkan slides
20150304 22:08:31 * Eclesia switch to red-cross code collector
20150304 22:08:42 <Eclesia> mbien: may I ask something ?
20150304 22:08:57 <mbien> of course
20150304 22:10:10 <Eclesia> mbien: do you have some ... unused code lying around ... dye on a usb stick or hard drive, stuff useless but maybe a bit usefull ? I'm collecting everything in public domain :) http://unlicense.developpez.com
20150304 22:11:43 <mbien> :)
20150304 22:12:32 <Eclesia> or you can throw me a brick ;)
20150304 22:13:54 <mbien> don't know if i find something reuseable. i usually tried to put everything on github what was semi-reuseable and not an experiment
20150304 22:15:45 <mbien> the rss feed agregator thing on jobamp for example. not sure if its still in use. "hungry harry"
20150304 22:16:46 <sgothel> @mbien: so what are you doing these days, if you don't mind to share?
20150304 22:17:24 <xranby_GTX580> mbien: it is! https://jogamp.org/blog/ Powered by Hungry Harry updated Mar 4, 10:51
20150304 22:17:59 <mbien> i am still freelancer. doing all kind of projects
20150304 22:21:26 <xranby_GTX580> mbien: do you have the planet2 "hungryharry" source on github?
20150304 22:21:44 <xranby_GTX580> i belive jogamp.org is running a version from hmm 2011
20150304 22:21:51 <xranby_GTX580> HungryHarry-SNAPSHOT-jar-with-dependencies.jar
20150304 22:21:58 <Eclesia> good night all ++
20150304 22:22:07 <sgothel> goody
20150304 22:22:14 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20150304 22:23:25 <mbien> https://github.com/mbien?tab=repositories should be there
20150304 22:23:54 <xranby_GTX580> https://github.com/mbien/Hungry-Harry/
20150304 22:23:56 <xranby_GTX580> indeed
20150304 22:24:44 <mbien> but i am pretty sure it has a license. don't know how unlicense works
20150304 22:25:17 <mbien> probably lgpl or bsd. don't know. was years ago
20150304 22:25:44 <sgothel> well, he is using 'public domain', which doesn't exist in Europe
20150304 22:26:00 <mbien> i see
20150304 22:26:07 <xranby_GTX580> i forked it to https://github.com/JogAmp/Hungry-Harry
20150304 22:26:15 <sgothel> so we came to an agreement, that he explicitly allow usage for other licenses, like BSD'ish .. us
20150304 22:26:48 <mbien> wait. you mean I was using public domain?
20150304 22:26:49 <sgothel> and I give him my express permission .. to use my lines of code for public domain - since I cannot speak for all committers :)
20150304 22:27:08 <sgothel> no, you not, AFAIK
20150304 22:27:29 <mbien> in any case i always hated licenses. such a waste of time. but its needed
20150304 22:27:39 <mbien> so i usually picked something what i picked before
20150304 22:27:55 <sgothel> @xerxes: thx
20150304 22:28:15 <mbien> the netbeans plugins where GPL is what i remembe.r don't know about the rest
20150304 22:29:32 <mbien> btw hungry harry is only a class or so :P not worth the trouble
20150304 22:33:01 <xranby_GTX580> i browsed the source, maven build scripts, so the dependencies list... rome, rome-fetcher, freemarker
20150304 22:33:27 <xranby_GTX580> rome-fetcher is APACHE 2 https://github.com/rometools/rome-fetcher/blob/master/LICENSE
20150304 22:33:56 <xranby_GTX580> rome is Apache 2 as well https://github.com/rometools/rome/blob/master/LICENSE
20150304 22:34:16 <xranby_GTX580> good to see that rome has an maintainer ex-sun
20150304 22:34:27 <mbien> wasn't there a maven command to list all licenses? :P
20150304 22:35:14 <mbien> oh no wait it was a netbeans plugin thing. they had that
20150304 22:35:22 <xranby_GTX580> freemarker: http://freemarker.org/docs/app_license.html
20150304 22:35:31 <xranby_GTX580> also apache2
20150304 22:36:03 <xranby_GTX580> after several copyright changes
20150304 22:36:14 <xranby_GTX580> Historical notes ---------------- FreeMarker 1.x was released under the LGPL license. Later, by community consensus, we have switched over to a BSD-style license. As of FreeMarker 2.2pre1, the original author, Benjamin Geer, has relinquished the copyright in behalf of Visigoth Software Society. With FreeMarker 2.3.21 the license has changed to Apache License, Version 2.0, and the owner has changed from Visigoth Software
20150304 22:37:49 <xranby_GTX580> net.java.dev.rome needs to be updated to the new com.rometools namespace
20150304 22:38:15 * hharrison (~chatzilla@anon) has joined #jogamp
20150304 22:42:21 <mbien> so this vulkan thing
20150304 22:42:31 <mbien> i still don't get the final vision of the project
20150304 22:42:58 <mbien> is it intended to be standalone in future or is it intended to be interfacing other khronos projects for ever
20150304 22:43:16 <mbien> standalone as in a replacement for GL and CL
20150304 22:43:29 <hharrison> I read it as a standalone thing, you could always build a GL/CL driver on top
20150304 22:44:09 <xranby_GTX580> mbien: in essence vulcan is AMD contributing its mantle API design to khronos... we are at day 2
20150304 22:44:22 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150304 22:45:29 <xranby_GTX580> http://community.amd.com/community/amd-blogs/amd-gaming/blog/2015/03/03/one-of-mantles-futures-vulkan The cross-vendor Khronos Group has chosen the best and brightest parts of Mantle to serve as the foundation for “Vulkan,” the exciting next version of the storied OpenGL API.
20150304 22:47:17 <mbien> so they explicitly mention "new and uniquely powerful graphics API" thats unexpected
20150304 22:50:43 <xranby_GTX580> mbien: the only known code parts are findings from photos and blogs collected here: http://vulkan-tutorial.com/
20150304 22:51:09 <mbien> thanks
20150304 22:51:29 <xranby_GTX580> for example the valve tool photo contains some API Calls
20150304 22:52:06 <mbien> looks like the CL api to me. just with vk instad of cl prefix ;)
20150304 22:52:09 <xranby_GTX580> the names matches 1:1 to the mantle api names with gr prefix replaced with vk prefix
20150304 22:52:32 <hharrison> Pushes all the mem allocation to the client, the driver ends up being just a place to put fences
20150304 22:53:04 <hharrison> One hopes the driver writers actually manage to write better drivers that way
20150304 22:53:30 <xranby_GTX580> i am happy when we ahve a amesa3d implementation
20150304 22:53:33 <xranby_GTX580> mesa3d
20150304 22:54:14 <hharrison> Solves a lot of problems by just defining an IR and a mem model, let people build interesting tools on top
20150304 22:55:38 <mbien> lets hope they get the implementaitons together earlier as with CL. was horrible back then. NV driver was replacing JVM interrupt handlers. you got a segfault on java exceptions :P
20150304 22:59:54 <hharrison> Yeah, it will be interesting to watch the drivers, the IR format looks a lot like the NIR work that they've been doing in mesa for the i965 driver
20150304 23:00:29 <hharrison> and I guess the VC4 driver as well now that Eric Anholt started using it as well
20150304 23:01:09 <hharrison> I see Connor Abbott is credited in the Vulkan doc as a contributer, he was the intern over there that did a ton of the NIR work
20150304 23:05:28 <xranby_GTX580> neat
20150304 23:05:35 <xranby_GTX580> kudos to Connor
20150304 23:06:50 <hharrison> It just makes me suspect a Vulkan runtime for intel drivers may not be too far off, they've obviously been planning ahead
20150304 23:15:33 <rmk0> i've been lurking in #dri-devel a bit
20150304 23:15:52 <rmk0> there was a suggestion that vulkan can't be done on current intel hardware due to some issues i didn't understand with the way textures are handled
20150304 23:18:34 <rmk0> something along the lines of it being possible to implement all of the bindless extensions (and therefore vulkan) except for bindless textures
20150304 23:27:07 <hharrison> interesting, don't really appreciate the hardware side enough to know why that would be
20150304 23:27:22 <rmk0> me neither
20150304 23:27:34 <sgothel> it would be nice if they will spec the common OpenCL/Vulkan infrastructure _identical_ (function pointers), then things could become quite neat
20150304 23:27:39 <hharrison> Makes me wonder just what the claim about 'anything that can support ES3.1 can support Vulkan'
20150304 23:27:57 <sgothel> lets say: compute is the trigger word here
20150304 23:28:16 <sgothel> Vulkan := compute + a bit of graphics semantics
20150304 23:31:18 <hharrison> Hmm, the OpenCL 2.1 provisional spec is out, does it speak at all to this?
20150304 23:31:37 <hharrison> Have they just moved closer, or is it fully shared semantics?
20150304 23:33:46 <sgothel> ^^ I would hope _same_ underlying infrastructure .. will look into details after our 2.3.0 release .. Wade signaled he likes to work on it as well
20150304 23:34:15 <sgothel> maybe .. for 3.0 jogamp, we can drop the pre OpenCL versions .. needs discussions for sure
20150304 23:34:51 <sgothel> at least a common set of interfaces for JOGL/JOCL ..
20150304 23:35:06 <sgothel> JOGL.VK that is ..
20150304 23:36:14 <sgothel> https://jogamp.org/bugzilla/showdependencytree.cgi?id=1137&hide_resolved=0 .. if you missed that
20150304 23:43:28 <sgothel> however .. I will setup up a branch next week, or maybe better a new repo, so we can share our experiments .. read: please contribute :)
20150304 23:50:36 <mbien> someone should write a master thesis about that. your son can't program yet? :P
20150304 23:51:34 <sgothel> he might be ready for the next big API coming after this one :)
20150304 23:51:45 <mbien> awesome :D
20150304 23:52:25 <sgothel> OpenGL 2003 - 2015
20150304 23:52:36 <mbien> i bet they cal vulcan 2 spock
20150304 23:53:11 <sgothel> I had the same idea .. hmm, but then, they were trekie addicted already
20150304 23:53:45 <sgothel> correction .. OpenGL 1992 - 2015 -> ~23 years
20150304 23:53:54 <sgothel> yes .. maybe he can do it earlier :)
20150304 23:54:21 <sgothel> Vulkan, ..: 2015 - 2035?
20150304 23:54:43 <sgothel> hmmm .. exponential change .. probably much earlier :)
20150304 23:57:40 <mbien> really currious how successfull it will be
20150304 23:58:57 <mbien> CL had always the driver issues since NV wanted to push cuda
20150304 23:59:07 <sgothel> IMHO it was a more huge step from compat FFP -> core PSP, then from core PSP -> core-Generic
20150304 23:59:11 * xranby_GTX580 (~familjen@anon) Quit (Quit: Leaving.)
20150304 23:59:52 <sgothel> many folks missed the FFP turtle graphics commands .. avoided core (.. when ES2 came out)
20150305 00:00:21 <sgothel> but now, I guess only the [hard]core is left in business anyways :)
20150305 00:00:46 <mbien> i was never a fan of ES. they should have made it a plain GL profile and call it.. gl profile
20150305 00:01:12 <sgothel> maybe they looked at JOGL .. when they adopted profiles :)
20150305 00:01:30 <mbien> possibly :)
20150305 00:06:28 <mbien> will endup being a seperate jogamp project i guess. interfacing with the other projects
20150305 00:13:32 <mbien> is dominik still around?
20150305 00:15:54 <sgothel> he got a diff. job .. 3d printer and the like AFAIK
20150305 00:16:30 <sgothel> not much contact .. none regarding jogamp lately
20150305 00:16:38 <mbien> kk
20150305 00:17:06 <sgothel> private life takes its toll .. hehe
20150305 00:18:23 <mbien> ^^
20150305 03:47:48 * mbien (~mbien@anon) Quit (Ping timeout: 252 seconds)
20150305 05:05:35 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150305050535.html