| 00:04.21 | Stragus | Vasco, so you imported some BVH code from somewhere? Eh, that works |
| 00:07.27 | Notify | 03BRL-CAD:vasco_costa * 65926 (brlcad/branches/opencl/include/rt/shoot.h brlcad/branches/opencl/src/librt/primitives/primitive_util.c brlcad/branches/opencl/src/rt/do.c): allow opencl lightmodel argument passing from the command line. |
| 00:12.11 | vasc | i think its MIT Licensed |
| 00:12.53 | vasc | only way to do in the schedule |
| 00:13.13 | vasc | there's a CUDA version of the code as well. dunno about any OpenCL version though. |
| 00:13.57 | vasc | there's a reason why i proposed the grid |
| 00:14.15 | vasc | decent quality bvh builders are quite hairy to implement |
| 00:14.25 | Stragus | Yes, it's quite a bit of code |
| 00:14.47 | Stragus | But that's a good solution. It's worth implementing things well or not at all, so that someone else will do it |
| 00:15.10 | vasc | well it can now render some scenes like 45x faster |
| 00:15.34 | vasc | brute force is gone |
| 00:16.03 | vasc | i think its like 4-5x faster than the cpu version right now |
| 00:16.16 | Stragus | Cool |
| 00:16.28 | vasc | well it doesn't do csg or a bunch of other things |
| 00:16.54 | Stragus | I thought it was only the BVH builder, working on abstract "objects" |
| 00:17.15 | Stragus | Where said objects can be CSG objects of specified weight/cost |
| 00:18.00 | Notify | 03BRL-CAD Wiki:Bhollister * 9353 /wiki/User:Bhollister/DevLogAug2015: /* Fri, August 14, 2015 */ |
| 00:18.06 | vasc | i'm only computing all intersections on the ray path and discarding those results that are behind something else |
| 00:18.26 | vasc | so i guess it only supports the union operator |
| 00:18.30 | vasc | ar ar |
| 00:18.40 | Stragus | :) It's a good starting point |
| 00:19.23 | bhollister3 | starseeker: patch #405 has been newly submitted. |
| 00:19.46 | vasc | btw i added that callback to process hits like you mentioned |
| 00:20.19 | Stragus | Cool, that will make it easier to extend functionalities |
| 00:21.02 | vasc | none of this is on trunk though. the memory allocations of the bvh builders are still a bit of a mess |
| 00:21.36 | Stragus | Is the BVH built as one chunk of memory or it's a mess of pointers? |
| 00:21.47 | vasc | its a linearized tree |
| 00:21.49 | vasc | one chunk |
| 00:21.52 | Stragus | That's good |
| 00:22.55 | Notify | 03BRL-CAD Wiki:Bhollister * 9354 /wiki/User:Bhollister/DevLogAug2015: /* Fri, August 14, 2015 */ |
| 00:22.59 | vasc | e.g. for the goliath it takes 0.08MB of RAM |
| 00:23.30 | vasc | but i'm using 255 primitives per leaf i think feh |
| 00:23.47 | Stragus | These are some heavy leaves |
| 00:23.48 | vasc | i'll need to figure out a proper setting eventually |
| 00:24.14 | Stragus | Consdering the high cost of intersection, leaves should be as small as possible |
| 00:24.36 | vasc | well on bvhs the leaves should be a bit bigger than on kd-trees |
| 00:24.39 | Notify | 03BRL-CAD Wiki:Bhollister * 9355 /wiki/MGED_CMD_nmg: |
| 00:24.45 | vasc | coz the bounding boxes take up a lot of space |
| 00:25.11 | vasc | but yeah the ideal trees are usually 'stringy' with few primitives per leaf |
| 00:25.17 | Stragus | Right |
| 00:25.38 | vasc | i'll eventually do some benchmarking to figure out a value |
| 00:26.33 | vasc | even with these big leaves it takes like half a second to render the goliath |
| 00:27.03 | Stragus | First hit only? |
| 00:27.13 | vasc | yeah |
| 00:27.35 | vasc | i think it takes like 1.5s to render it with BRL-CAD proper |
| 00:27.39 | Stragus | Darn |
| 00:27.48 | vasc | well the boxes a kinda big |
| 00:27.51 | vasc | are |
| 00:28.07 | vasc | it's just changing some constant somewhere |
| 00:28.33 | Stragus | Normally, it should be changing the traversal cost weights of the objects... |
| 00:28.36 | vasc | i usually see 8x speedup when i port things to gpu |
| 00:28.42 | vasc | but this one is more like 4-5x |
| 00:28.52 | Stragus | The BRL-CAD raytracer doesn't use SSE/AVX |
| 00:28.56 | vasc | coz of the doubles |
| 00:29.01 | Stragus | Oh right, doubles |
| 00:29.45 | Stragus | The float speed-up would normally be about 60x, but with these doubles, it might go from 2x to 20x |
| 00:29.57 | vasc | nah it ain't that good |
| 00:30.19 | vasc | not against MT and SIMD CPU code |
| 00:30.36 | vasc | but OpenCL can run on the CPU as well |
| 00:30.47 | Stragus | BRL-CAD's raytracer doesn't use any SSE/AVX |
| 00:30.54 | vasc | it does now :-) |
| 00:31.01 | Stragus | Through OpenCL? |
| 00:31.03 | vasc | yeah |
| 00:31.09 | Stragus | Does that work well? |
| 00:31.38 | vasc | i have to change the code and recompile to check. there's no command line option to select device yet. it just picks the first on the list |
| 00:32.31 | vasc | no i didn't code that |
| 00:33.14 | vasc | i have an AMD FX 8350 |
| 00:34.42 | vasc | 0.18 sec for that scene that takes 0.09 sec on the GPU |
| 00:34.53 | vasc | its only 2x faster on the GPU |
| 00:35.15 | Stragus | There's plenty of optimization work left, but you apparently did a big chunk |
| 00:35.32 | vasc | the memory writes need to be optimized a lot |
| 00:35.33 | Stragus | I have a lot of CUDA experience but I have never used doubles, I'm not sure what to expect |
| 00:36.11 | Stragus | Highly parallel code can be 20x faster on a single GPU than multi-threaded SSE/AVX optimized numa-aware CPU code |
| 00:36.18 | Stragus | ... with floats |
| 00:36.23 | vasc | right |
| 00:36.45 | vasc | but i usually see more like 8x |
| 00:37.11 | vasc | its the damned thread divergence |
| 00:38.16 | vasc | that's the thing with OpenCL. it can target a lot of architectures |
| 00:38.21 | vasc | even if the tools kinda suck |
| 00:38.40 | vasc | the language itself is perfectly fine |
| 00:38.52 | vasc | with some exceptions |
| 00:38.54 | Stragus | OpenCL code always needs to target a specific architecture if you want good performance |
| 00:39.00 | vasc | well yeah but |
| 00:39.06 | vasc | you can say the same for C code |
| 00:39.16 | Stragus | Even with CUDA, I have plenty of #if depending if I'm running on Fermi, Kepler or Maxwell |
| 00:39.42 | Stragus | Well... yes, except most C code runs on x86 chips with few differences |
| 00:39.49 | vasc | today maybe |
| 00:39.57 | vasc | all the world is either x86 or ARM |
| 00:40.26 | vasc | x86 on laptops and above and ARM on tablets and below |
| 00:40.32 | Stragus | Right |
| 00:40.43 | Stragus | Optimization guidelines on ARM are fairly close to x86 |
| 00:41.12 | vasc | the only quirky thing it had that i remember was that branch target bit or whatever |
| 00:42.08 | vasc | i never did assembly on ARM |
| 00:42.17 | vasc | only x86 |
| 00:42.26 | vasc | and MIPS i guess but that was on paper |
| 00:42.28 | vasc | :-) |
| 00:43.09 | Stragus | MIPS, that still exists? :) |
| 00:43.33 | Stragus | I read a lot on ARM and NEON, just to reassure myself that not all architectures have to be as poorly designed as x86 |
| 00:43.41 | vasc | well the hennessy and patterson books uses MIPS and DLX |
| 00:43.53 | vasc | yeah x86 is pretty bad |
| 00:43.59 | Stragus | Although I found the ISA of all CUDA hardware fantastic |
| 00:44.05 | vasc | yes me too |
| 00:44.13 | vasc | lots of nice instructions and its quite orthogonal |
| 00:44.52 | vasc | the x86 did get a lot better with i386 and x86-64 though |
| 00:45.12 | Stragus | The weight of legacy is terrible |
| 00:45.31 | vasc | AMD at one point wanted to replace x87 but eventually they gave up |
| 00:45.41 | vasc | i think they called it the Technical Floating Point instructions |
| 00:45.43 | vasc | three operand FP |
| 00:45.49 | vasc | no stack shit |
| 00:45.56 | Stragus | The "Clear the interrupt flag" instruction is just one byte, but the "dot product" SSE 4.1 instruction is 5 (!!) bytes, plus 2 bytes for operands and two prefixes, so 9 bytes |
| 00:46.16 | vasc | it's got seniority |
| 00:46.51 | vasc | all the flags instructions on x86 are probably going to bite them in the ass in the future |
| 00:47.19 | vasc | it makes wide processors a problem |
| 00:47.21 | Stragus | Yes... and implicit operands not allowing good parallelism, all instructions modifying flags, etc. |
| 00:47.53 | Stragus | The worst problem is probably the guaranteed L1 cache synchronization between cores, it makes scalability very troublesome for the hardware |
| 00:47.56 | vasc | does PTX even have flags? i don't think so |
| 00:48.21 | Stragus | CUDA hardware could have a million cores, but x86? Ah... we have serious headaches going above 16 |
| 00:48.35 | vasc | well the Xeon Phi has quite a lot of them |
| 00:48.44 | Stragus | All cores need to talk to each other to synchronize their L1 cache due to memory coherency guarantees of the architecture |
| 00:49.10 | vasc | yeah that particular choice of memory protocol wasn't probably the best either |
| 00:49.50 | vasc | Xeon Phi 61 cores |
| 00:50.31 | Stragus | I wonder if they relaxed the memory coherency guarantees, requiring actual memory fences |
| 00:52.37 | Stragus | Apparently not, it features the same x86 cache coherence guarantees |
| 00:52.43 | vasc | i think they had this ring bus |
| 00:52.48 | vasc | in the early ones |
| 00:52.52 | vasc | connecting the processors |
| 00:52.57 | vasc | i mean the cores |
| 00:52.58 | Stragus | Right |
| 00:54.08 | vasc | it's probably the next iteration of the Intel fail architecture for the technical computing market |
| 00:54.26 | vasc | which will join the i860, Itanium |
| 00:54.30 | Stragus | Yup |
| 00:54.48 | vasc | it's too big and hot |
| 00:55.00 | vasc | something that can only sell for the server market ain't gonna do it |
| 00:55.28 | Stragus | It's not even good. A consumer-grade GPU beats a $2k Xeon Phi |
| 00:55.33 | vasc | if anything the gpus might eventually enter their space. |
| 00:56.11 | vasc | what's that nvidia thingie called.... i think its Denver |
| 00:56.51 | vasc | ah no they changed the name |
| 00:57.04 | vasc | or not |
| 00:57.34 | Stragus | The ARM CPU in Nexus 9? |
| 00:58.09 | vasc | yeah |
| 00:58.17 | vasc | it's ARM compatible but its not an ARM chip design |
| 00:58.51 | vasc | its their answer to the Itanium i guess. snark. |
| 00:59.08 | vasc | its some kind of VLIW with code morphing. now that would be transmeta i guess. |
| 00:59.41 | vasc | it's weird that one |
| 00:59.54 | Stragus | Yes, I never really read anything about it |
| 01:00.03 | vasc | allegedly NVIDIA wanted to do x86 compat. not ARM compat for the Denver. |
| 01:00.14 | vasc | then they switched to supposedly being able to target both |
| 01:00.29 | vasc | then i think they hit a slight snag with Intel patent licensing |
| 01:00.50 | Stragus | I want a CPU where I can reprogram the instruction decoder |
| 01:00.57 | vasc | or at least that's how the rumour mill went |
| 01:01.26 | vasc | Denver is 7-wide |
| 01:01.38 | Stragus | Look ago, I looked into writing AMD micro-code to reprogram the instruction decoding |
| 01:01.55 | Stragus | Not surprisingly, information was *very* scarse |
| 01:02.07 | vasc | yeah. imagine removing a virus in that. |
| 01:02.13 | Stragus | Long* ago |
| 01:02.25 | Stragus | Eh, yes |
| 01:02.25 | vasc | i think the PAL on the Alpha was programmable. |
| 01:02.34 | vasc | they used it for VAX emulation and stuff like that. |
| 01:02.39 | Stragus | All modern x86 CPUs have programmable microcodes |
| 01:02.52 | Stragus | Except that Intel and AMD are keeping their mouth completely shut on the topic |
| 01:03.15 | vasc | well people might find out how many bugs their processors really have it they didn't |
| 01:03.34 | vasc | i think i read that Intel disabled TSX recently |
| 01:03.36 | Stragus | I had figured out that all AMD "direct path" instructions were not programmable, but the "vector path" instructions were interpreted by the microcode |
| 01:03.57 | vasc | well |
| 01:04.05 | vasc | it takes a long time to design a processor |
| 01:04.20 | vasc | and Intel keeps changing the instruction set and not telling anyone about it until its too late |
| 01:04.25 | vasc | so microcode to the rescue. |
| 01:04.33 | Stragus | Eheh |
| 01:05.12 | Stragus | wants to reprogram the opcode map so that all common SSE/AVX instructions get a single byte opcode |
| 01:05.32 | vasc | to improve code density? that's interesting. |
| 01:05.51 | vasc | but the short ones are prolly reserved. |
| 01:05.53 | Stragus | Many modern processors actually choke on the instruction decoding |
| 01:06.08 | Stragus | Instruction decoding is a bottleneck in many cases, due to the SSE/AVX instruction taking so many bytes and prefixes |
| 01:06.27 | vasc | yeah x86 has so many additions and changes its like a kiltwork ISA |
| 01:06.46 | vasc | quilt work |
| 01:06.58 | Stragus | We have 1 byte opcodes to do things like "add 1 to eax" and so on |
| 01:07.14 | vasc | that one actually makes sense |
| 01:07.40 | vasc | there's also the fabled XOR EAX, EAX coz its smaller than MOV EAX, 0 |
| 01:08.16 | Stragus | Okay... what about the single byte "aad" instruction, ASCII adjust AX before division by 10? :) |
| 01:08.38 | vasc | it probably made sense when they wanted to sell POS. you know cash registers. |
| 01:08.53 | vasc | that and the BCD mode crap. |
| 01:09.18 | Stragus | Yes, it's part of the many BCD instructions, opcodes all taking a single byte |
| 01:09.49 | Stragus | Or other one-byte instructions like "bounds", check if a number is between two numbers or not |
| 01:09.56 | vasc | i think we used that in the lab when i was an undergrad to program this segmented LED display |
| 01:10.40 | vasc | i think the string instructions are even more useless |
| 01:10.59 | Stragus | Oh, did you know that the "inc" (increment) and "dec" (decrement) instructions have a single-byte opcode for every single register? |
| 01:11.27 | *** join/#brlcad vasc__ (~vasc@bl13-126-172.dsl.telepac.pt) |
| 01:12.00 | Stragus | Oh, did you know that the "inc" (increment) and "dec" (decrement) instructions have a single-byte opcode for every single register? |
| 01:12.03 | Stragus | Opcode 40h: inc ax, opcode 41h: inc cx, opcode 42h: inc dx, opcode 43h: inc sp |
| 01:12.13 | Stragus | We have *that* and we have 9 bytes dot products |
| 01:12.36 | vasc__ | they probably thought it made sense at the time |
| 01:13.03 | vasc__ | i think the x86 was based on some processor that was in turn based on another processor that was an accumulator architecture |
| 01:13.04 | vasc__ | only one register |
| 01:13.37 | Stragus | Right... Someone somewhere should have figured out that we needed to clean up that crap when the ISA went 32 bits, then 64 bits |
| 01:13.43 | vasc__ | they prolly thought it would be more orthogonal and kept doing that crap when they added registers |
| 01:13.53 | Stragus | And now, it's stuck with us forever since there won't be a 128 bits |
| 01:13.59 | vasc__ | the 64bits cleaned it up a teensy bit i think |
| 01:14.16 | vasc__ | who knows... |
| 01:14.55 | Stragus | Oh actually, the inc/dec mess did become prefixes on 64 bits |
| 01:15.02 | vasc__ | see |
| 01:15.13 | vasc__ | yeah i think they reused one of two of those instructions |
| 01:15.26 | vasc__ | the VEX prefit or whatever. or was it REX. |
| 01:15.28 | Stragus | Right |
| 01:15.44 | Stragus | They still should have cleaned up a little more, but eh |
| 01:16.01 | vasc__ | well |
| 01:16.18 | vasc__ | AMD had the prior experience with the Technical Floating Point extensions |
| 01:16.41 | vasc__ | from what i heard the compiler writers and OS writers (prolly MS) didn't want to add support |
| 01:16.51 | vasc__ | so they dropped it and implemented compatibility with SSE |
| 01:16.55 | vasc__ | 2 |
| 01:16.58 | Stragus | Never heard of that before. Is it 3dnow?... |
| 01:17.03 | vasc__ | no |
| 01:17.11 | vasc__ | it was three operand floating point ala RISC |
| 01:17.23 | vasc__ | non-vector |
| 01:17.43 | Stragus | Google isn't finding much either |
| 01:18.06 | vasc__ | http://arstechnica.com/civis/viewtopic.php?f=8&t=530111 |
| 01:18.32 | vasc__ | the big thing was the FMA support |
| 01:18.35 | vasc__ | IIRC |
| 01:18.39 | vasc__ | three operand FMA |
| 01:19.24 | vasc__ | it would have doubled peak FP performance on x86 vs x87 i think |
| 01:19.36 | vasc__ | and coz of no more stack the performance would also be better |
| 01:19.37 | Stragus | Cool, thanks |
| 01:19.46 | vasc__ | they eventually gave up |
| 01:19.58 | Stragus | AMD preferred to follow Intel on the SSE path |
| 01:20.35 | vasc__ | they had the experience with 3dnow |
| 01:20.39 | vasc__ | and 3dnow! |
| 01:20.55 | vasc__ | it's hard to convince software writers |
| 01:21.04 | vasc__ | the tools guys |
| 01:21.19 | vasc__ | so they gave up and went the SSE, whatever way |
| 01:21.44 | vasc__ | had they done the TFP i think X87 FP on 64-bit mode would be dead |
| 01:22.05 | Stragus | They should have thrown the x87 out on 64 bits |
| 01:22.21 | vasc__ | well the ISA says that SSE is the default FP mode |
| 01:22.29 | vasc__ | i think |
| 01:22.35 | vasc__ | SSE2 actually |
| 01:22.35 | Stragus | Yes... |
| 01:22.46 | Stragus | But the x87 is taking a *ton* of precious 1 byte opcodes! |
| 01:22.56 | Stragus | Seriously, like 40 of them |
| 01:22.57 | vasc__ | does it have those? |
| 01:23.02 | Stragus | Yes |
| 01:23.11 | vasc__ | i mean it was designed by those guys at Intel Haifa as an afterthought |
| 01:23.25 | vasc__ | let the Israelis do this crap no one needs |
| 01:24.00 | vasc__ | i think they had a limited opcode space so they went with that stack abortion ISA as a compromise |
| 01:24.28 | Stragus | Hum yes, it's just 16 one-byte opcodes after all, 0xD* |
| 01:24.53 | Stragus | They play in bits in the ModRM byte to change the instructions |
| 01:25.56 | Stragus | Since an operand is always the first x87 register on top of the stack, they have an extra 3 bits for every one-byte opcode |
| 01:26.06 | Stragus | So each one-byte opcode actually holds 8 different instructions |
| 01:26.15 | Stragus | It's both clever and incredibly nasty |
| 01:26.50 | vasc__ | it must make that instruction decoder really swell to do |
| 01:28.26 | Stragus | What a mess, 3 bits of the byte that identifies register operands actually change the instruction |
| 01:28.43 | Stragus | wouldn't want work in x86 CPU design |
| 01:29.15 | vasc__ | it's crap piled on more crap |
| 01:29.54 | vasc__ | like i said only i386 and x86-64 provide some reprieve |
| 01:30.12 | vasc__ | even if its still suboptimally encoded |
| 01:30.41 | Stragus | You are certainly right that they designed that whole x87 stack because they didn't have enough opcode space |
| 01:30.52 | Stragus | It shows just by reading the instruction encoding |
| 01:31.50 | vasc__ | stack processors were actually a fad at one point. actually several points. |
| 01:32.03 | vasc__ | latest was prolly the java processor crap |
| 01:32.10 | vasc__ | picojava |
| 01:32.53 | Stragus | I completely fail to see any advantage, except perhaps higher instruction encoding density due to an implicit argument |
| 01:33.09 | vasc__ | yeah that's the usual |
| 01:33.12 | Stragus | But you could have the same thing with regular registers, a very fast xchg and implicit eax instructions |
| 01:37.09 | vasc__ | i don't think CISC is necessarily a bad idea |
| 01:37.16 | vasc__ | but X86 is a bad CISC |
| 01:37.46 | Stragus | CISC should never have hardcoded registers |
| 01:38.12 | Stragus | And CISC should implement useful instructions for the future, no whatever Intel found easier/cheaper to implement at that point in time |
| 05:17.00 | *** join/#brlcad merzo (~merzo@38-109-133-95.pool.ukrtel.net) |
| 06:32.51 | Notify | 03BRL-CAD:vasco_costa * 65927 brlcad/branches/opencl/src/rt/do.c: fix pointer bugs in the hlbvh builder. change max leaf size to 4 solids. |
| 07:33.05 | *** join/#brlcad merzo (~merzo@134-32-133-95.pool.ukrtel.net) |
| 08:01.24 | *** join/#brlcad roop (~roop@106.76.156.16) |
| 08:39.10 | *** join/#brlcad merzo (~merzo@140-107-132-95.pool.ukrtel.net) |
| 09:15.54 | *** join/#brlcad merzo (~merzo@109-52-133-95.pool.ukrtel.net) |
| 09:43.55 | *** join/#brlcad shaina (~shaina@61.0.200.41) |
| 10:32.10 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 10:39.40 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 10:52.02 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-qeyccaegxmasrrzf) |
| 11:30.14 | *** join/#brlcad konrado (~konro@41.205.22.10) |
| 13:25.42 | Notify | 03BRL-CAD:ejno * 65928 (brlcad/trunk/src/libgcv/bot_solidity.c brlcad/trunk/src/libgcv/plugin.c brlcad/trunk/src/libgcv/plugin.h): formatting; use const pointers |
| 14:47.12 | Notify | 03BRL-CAD:vasco_costa * 65929 (brlcad/branches/opencl/include/rt/shoot.h brlcad/branches/opencl/src/librt/primitives/primitive_util.c brlcad/branches/opencl/src/rt/do.c): refactor hlbvh api. |
| 15:42.40 | *** join/#brlcad konrado (~konro@41.205.22.32) |
| 15:47.29 | *** join/#brlcad vasc (~vasc@bl13-126-172.dsl.telepac.pt) |
| 15:53.15 | Notify | 03BRL-CAD:vasco_costa * 65930 (brlcad/branches/opencl/include/bu/malloc.h brlcad/branches/opencl/src/libbu/malloc.c brlcad/branches/opencl/src/rt/do.c): memory pools to manage bvh node creation memory. |
| 15:59.30 | Notify | 03BRL-CAD:vasco_costa * 65931 (brlcad/trunk/include/bu/malloc.h brlcad/trunk/src/libbu/malloc.c): memory pools. |
| 16:12.09 | Notify | 03BRL-CAD:vasco_costa * 65932 (brlcad/trunk/include/rt/shoot.h brlcad/trunk/src/librt/primitives/arb8/arb8_shot.cl and 9 others): opencl linear bvh traversal. |
| 16:26.30 | starseeker | bhollister3: apologies for not being around on Fri - didn't have internet access |
| 16:45.28 | *** join/#brlcad gurwinder (~chatzilla@59.91.237.53) |
| 17:02.13 | Notify | 03BRL-CAD:ejno * 65933 brlcad/trunk/src/librt/primitives/bot/gct_decimation/meshdecimation.c: silence warning |
| 17:15.48 | Notify | 03BRL-CAD:starseeker * 65934 (brlcad/trunk/src/libged/brep.c brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp): Add support for custom colors to a few more brep plotting routines. |
| 17:18.28 | starseeker | konrado: if we're going to require that libxml be installed, it'll need to move to src/other |
| 17:18.38 | starseeker | konrado: (sorry, catching up) |
| 17:25.38 | starseeker | konrado: did you happen to take a look at irrXML as used by assimp? https://github.com/assimp/assimp/tree/master/contrib/irrXML |
| 17:26.08 | starseeker | konrado: if that can do what is needed, I suspect it would be a much simpler dependency to manage than libxml et. al. |
| 17:28.21 | starseeker | would need slight rework to make it "properly" contained but since assimp is using their version in geometry file conversion it will hopefully be well matched to our own needs |
| 17:34.57 | *** join/#brlcad konrado_ (~konro@41.205.22.38) |
| 17:37.10 | konrado | starseeker: Thanks for the response, I would look into all what you have said and get back to you latter. |
| 17:37.35 | starseeker | konrado: if we do need libxml we can do that, but it's likely going to require more build work than just adding install rules |
| 17:38.20 | starseeker | iirc there was quite a lot in there, and the existing CMake files are targeted solely at getting enough of it working to do our docbook build and validation in a cross platform fashion |
| 17:39.04 | starseeker | I'd want to do a more thorough job of it if libxml graduates to an installed 3rd party src/other dep |
| 17:39.47 | starseeker | konrado: if it would help for me to break out a stand-alone version of the assimp irrxml fork I can probably do that fairly quickly - let me know |
| 17:43.04 | *** join/#brlcad konro__ (~konro@41.205.22.43) |
| 17:44.43 | starseeker | sxmlc might also be worth a look if irrXML proves inadequate for some reason - it seems to be maintained |
| 17:45.10 | starseeker | but assimp's needs are likely to map very well to ours in this area |
| 17:45.55 | starseeker | is still partial to the idea of hooking them under libgcv to handle bot formats... |
| 18:10.06 | *** join/#brlcad bhollister (~brad@2601:647:cb01:9750:b530:224b:6c3:7974) |
| 18:21.47 | *** join/#brlcad konrado (~konro@41.205.22.12) |
| 18:34.10 | *** join/#brlcad ries_nicked (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 18:34.50 | Notify | 03BRL-CAD:vasco_costa * 65935 brlcad/branches/opencl/src/rt/do.c: remove experimental grids code. |
| 18:37.05 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9356 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 18:42.30 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9357 /wiki/Povray: |
| 18:43.18 | Notify | 03BRL-CAD Wiki:Gurwinder Singh * 9358 /wiki/Povray: |
| 20:05.06 | Notify | 03BRL-CAD Wiki:106.76.158.73 * 9359 /wiki/User:Hiteshsofat/GSoc15/log_developmen: |
| 20:34.47 | Notify | 03BRL-CAD:vasco_costa * 65936 brlcad/branches/opencl/src/rt/do.c: refactor bvh builder to accept a list of centroids and boxes instead of primitives. |
| 20:49.22 | *** join/#brlcad gaganjyot (~vikram@117.253.227.160) |
| 20:57.27 | *** join/#brlcad Ch3ck_ (~Ch3ck@41.205.19.154) |
| 21:54.30 | *** part/#brlcad Ch3ck_ (~Ch3ck@41.205.19.154) |
| 22:03.08 | Notify | 03BRL-CAD:vasco_costa * 65937 (brlcad/branches/opencl/include/rt/defines.h brlcad/branches/opencl/include/rt/shoot.h and 3 others): move bvh builder to librt. |
| 22:19.54 | Notify | 03BRL-CAD:vasco_costa * 65938 (brlcad/trunk/include/rt/defines.h brlcad/trunk/include/rt/shoot.h and 2 others): add hlbvh cpu builder to trunk. |
| 22:28.35 | Notify | 03BRL-CAD:vasco_costa * 65939 brlcad/branches/opencl/src/librt/cut.c: improve comments. |
| 22:32.11 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9360 /wiki/User:Vasco.costa/GSoC15/logs: /* Week 12 : 10 Aug-16 Aug */ |
| 22:32.54 | Notify | 03BRL-CAD Wiki:Vasco.costa * 9361 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Status */ |