IRC log for #brlcad on 20170623

00:19.53*** join/#brlcad infobot (~infobot@rikers.org)
00:19.53*** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;)
00:27.59*** join/#brlcad efjrugungwcmohmu (~armin@dslb-092-075-157-134.092.075.pools.vodafone-ip.de)
03:41.06*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
04:40.52Notify03BRL-CAD Wiki:Ravilogaiya * 0 /wiki/User:Ravilogaiya:
05:31.46*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
05:32.36*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
05:33.21*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
05:34.12*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
05:35.02*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
05:35.46*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
06:04.33*** join/#brlcad KimK (~Kim__@2600:8803:7a81:7400:69b5:1646:8ec0:c796)
06:34.41*** join/#brlcad DaRock (~Thunderbi@mail.unitedinsong.com.au)
06:58.47*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
07:36.20*** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar)
07:43.44*** join/#brlcad merzo (~merzo@93.94.41.67)
07:49.32Notify03BRL-CAD:Amritpal singh * 10057 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */
07:53.11Notify03BRL-CAD:Amritpal singh * 10058 /wiki/User:Amritpal_singh/GSoC17/logs: /* Coding Period */
08:12.20*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
08:34.21*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
08:51.53*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
10:38.01*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
11:43.38*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
11:46.04*** join/#brlcad d_rossberg (~rossberg@104.225.5.10)
12:15.57*** join/#brlcad DaRock (~Thunderbi@mail.unitedinsong.com.au)
12:19.55*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
12:58.55*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
13:33.22*** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-aihythsembbzujjz)
13:48.51d_rossberggabbar1947: i run on a cmake error: inlude/rt/primitives/annot.h isn't there, and annot.h is twice inserted in the CMakeLists.txt
13:49.40gabbar1947I'll check, give me a second
13:51.40gabbar1947Rectified: I'm building on my system, just a moment
14:03.08gabbar1947Uploaded, this should pass
14:07.08d_rossberggabbar1947: what is your intention behind your changes to the root CMakeLists.txt
14:07.14d_rossberg?
14:08.31*** join/#brlcad yorik (~yorik@2804:431:f720:80d8:290:f5ff:fedc:3bb2)
14:08.55gabbar1947Actually I did not make any changes to the file, Its somehow reflected in the patch.
14:09.01gabbar1947I'll check once
14:10.12gabbar1947I'm unaware of any such change made by me, I have no idea why this reflects in the patch
14:12.21d_rossbergi'm recommending looking at a patch file with a text editor and to check if it looks reasonable
14:13.18gabbar1947I'll revert the change to the CmakeList.txt,  Is there anything else that you want me to look into ?
14:13.36d_rossbergin addition you have trailing spaces in your code
14:14.13d_rossbergthe "good" text editors provide a function to remove them all in one step
14:14.58gabbar1947I tried to remove as much as I could, anyways I'll go through the files once again. I'll use a text editor other than vim.
14:16.41d_rossberggoogle says in vi it is :%s/\s\+$//e
14:18.22d_rossbergsee https://vi.stackexchange.com/questions/454/whats-the-simplest-way-to-strip-trailing-whitespace-from-all-lines-in-a-file/
14:18.22gcibot[ What's the simplest way to strip trailing whitespace from all lines in a file? - Vi and Vim Stack Exchange ]
14:18.35d_rossbergand its reference to vim.wikia
14:18.43gabbar1947works! thank you
14:19.45gabbar1947On it! just a moment  
14:22.20d_rossbergi wrote my documents with vi for many years, you can write great literature with it - if you are tough enough for it
14:29.50gabbar1947can you give it a try now, and let me know if there are more errors !
14:34.33d_rossbergok: typein.c has trailing spaces and a C++ comment (i.e. //)
14:35.41d_rossbergmaybe you should simply remove the line - and the number of segments in p_annot for the sake of simplicity (see seans mail)
14:35.52gabbar1947I'll remove it ! The C++ instinct !
14:38.01gabbar1947Actually I wanted the "l" command to display the annotation container details as well, that was the reason for its inclusion. anyways i'm removing it!
14:38.13d_rossbergrun the :%s/\s\+$//e on all files you've touched to make sure that no trailing space left
14:38.38d_rossbergisn't typein.c the in command?
14:42.31d_rossbergsorry, i had an old patch, in the actual one all trailing spaces seem to be gone
14:42.40gabbar1947:)
14:43.41gabbar1947typein.c is the "in" command! but for the describe() function for annotation displays the container params as well, so just wanted to see the details on the screen, that's it !
14:44.22d_rossbergok, it's on your decision
14:46.58gabbar1947I'm submitting the patch, once build completes !
14:55.45gabbar1947UPLOADED
14:59.34d_rossberghowever, i've to go now :(
14:59.41d_rossbergi'll see ...
15:11.36gabbar1947:)
15:38.26*** join/#brlcad merzo (~merzo@93.94.41.67)
15:49.55*** join/#brlcad vasc (~vasc@bl14-42-31.dsl.telepac.pt)
15:50.01vaschey
15:50.04vaschello mdtwenty[m]
15:50.23mdtwenty[m]Hi :)
15:51.02vascso... you said something about only supporting one partition?
15:52.03mdtwenty[m]not only one partition.. one region
15:52.09vascright.
15:52.52vascbut that isn't in the weaving part proper right?
15:52.58vascit's in the evaluation for rendering?
15:53.37mdtwenty[m]yes it in the evaluation part
15:53.51vascwell. you haven't implemented rt_boolfinal yet.
15:54.35vascis there anything left to do in the boolean weaving?
15:55.36mdtwenty[m]i don't think so.. i think the boolean weaving is already fine
15:56.10mdtwenty[m]i was looking now into the rt_boolfinal
15:58.02mdtwenty[m]*i also uploaded today the weave patch without using the pointers in the cl_partition structure
15:58.38vascyes. i've seen that. i'll have to review it more in depth later but it seems fine on a cursory glance.
15:59.28vascthere's still the question of linked lists vs arrays, but without more complex test scenes there's no good way to benchmark it.
16:02.15vascthe most complex test scenes on the standard database files are probably goliath and havoc. but i'm not sure if they use much csg
16:02.35vascthey probably don't.
16:03.07vaschave you tried rendering those to see what happens?
16:03.15vascand the operators scene.
16:03.22vascoh right. rendering issues.
16:03.34vascwell.
16:03.38mdtwenty[m]the havoc and the goliath?
16:03.47vascyes. havoc.g and goliath.g i think
16:03.53vascin share/db or something.
16:04.05mdtwenty[m]yes i see it
16:04.08mdtwenty[m]one sec
16:04.38vascif it doesn't crash that would be good enough i guess.
16:04.43vascfor now.
16:05.27vaschopefully it's not horrendously slow either.
16:06.23mdtwenty[m]hm the goliath scene fails the assertion of 32 segments per ray
16:06.30mdtwenty[m]so i think 32 is not enough
16:06.30vaschah.
16:06.50vascsee what's the max depth.
16:07.41vascit's still prolly under 64,.
16:08.24vasci think i have some dynamic bitvector code in opencl or ANSI C in here somewhere you could use if it's bigger than that.
16:11.35mdtwenty[m]is there a function to see what is the max depth or something?
16:12.22vascno. just in that for loop where you do the assert, keep track of the max segments per ray size, and then print it out when the loop ends.
16:13.18vascthere might be something like that in one of the brlcad tools, but i'm not sure if it would work with the opencl backend.
16:20.00vascok found it
16:20.01vasc== host
16:20.02vasccl_uint ND = N/WORD_BITS + 1;
16:20.02vascmD = clCreateBuffer(gpuCtx, CL_MEM_READ_WRITE, sizeof(cl_uint) * ND, NULL, NULL);
16:20.02vasc== device
16:20.02vascinline uint bindex(const uint b) {
16:20.03vasc<PROTECTED>
16:20.05vasc}
16:20.07vascinline uint bmask(const uint b) {
16:20.09vasc<PROTECTED>
16:20.11vasc}
16:20.13vascinline uint isset(__global uint *bitset, const uint b) {
16:20.15vasc<PROTECTED>
16:20.17vasc}
16:20.19vascinline uint clr(__global uint *bitset, const uint b) {
16:20.21vasc<PROTECTED>
16:20.23vasc}
16:20.25vascinline uint set(__global uint *bitset, const uint b) {
16:20.27vasc<PROTECTED>
16:20.29vasc}
16:20.31vasc-
16:20.33vascthis is my code, so i give you permission to it for any purpose.
16:20.49vascwhere WORD_BITS is 32 since 'D' is an array of cl_uints
16:21.33vascand N is the amount of bits you want the bitvector to have.
16:21.42mdtwenty[m]i got maxdepth of 957571
16:21.48vascWHAT
16:21.52vascdo the math properly dude.
16:21.58vasc:-)
16:22.02vascthat can't be truel.
16:22.13vascmax per segment, not the sum of everything.
16:22.55StragusStill not a fan of allocating chunks out of big buffers through atomics, eh :)
16:23.27vascwe might do that eventually. but for now there's a lot of gfx card memory we don't use.
16:24.01StragusAll right. It goes up quickly when buffering all hits for millions of rays
16:24.52vascwell sure. we could find the warp size and only allocate a buffer of that size or something.
16:24.57vascit's too much work :-)
16:25.27vascthose microoptimizations can be done later.
16:25.59vasci kinda doubt we need to do it this way anyway.
16:26.12vasci suspect we could do the csg processing in an iterative fashion with a modified algorithm.
16:26.48StragusSo you want to allocate the "max depth" for every ray... and how do you determine that max depth?
16:27.22vascwe count the amount of segments per before allocating and actually storing the segments.
16:27.33vascwe count the amount of segments per ray before allocating and actually storing the segments.
16:27.37StragusIdeally, you would process the segments as they come rather than buffering the whole thing. That complicates the code though
16:27.51StragusAh yes, the two passes thing, count then trace
16:28.04vascyeah i suspect that could be done across the whole pipeline, but it requires rethinking the algorithm.
16:28.14vascit's probably non-trivial. but yeah it's worthwhile in the long run.
16:28.48vasci'm just kinda reticent about doing it first hand without understanding how the current algorithm works properly.
16:29.14vascnot just mechanically but in terms of performance as well.
16:29.40StragusMy raytracer used an inlined callback, the user could do whatever it wants with the hits. They can be processed on the fly (recommended) or buffered by a custom solution in the callback. And importantly, the inlined callback can terminate rays early
16:29.48vascespecially considering the guys who originally wrote the code didn't do it, and they worked on it for decades.
16:30.10vascwell, we kind of have something like that,
16:30.36vascthere's no storing of segments in the single pass version of the renderer.
16:30.45StragusCool. Is the callback truly inlined? You want to avoid any function call on GPU, especially function pointers
16:30.45vascbut that doesn't do CSG.
16:31.09vascand it only returns the first hit, or an accumulation of the result of all the hits.
16:31.28vascyou can't have function pointers on opencl.
16:31.40vascbut yeah its some function.
16:31.45StragusEheh. You can with CUDA, but it's a Very Bad Idea anyway
16:32.38mdtwenty[m]i was doing it wrongly :D
16:32.58vascthat version of the renderer is way faster than the current ANSI C one.
16:33.04mdtwenty[m]i got 493 maxdepth for the goliath and 105 for the havoc
16:33.12vascbut it doesn't do CSG so it isn't a proper comparison
16:33.16vascreally?
16:33.21vascit's still way more than i expected.
16:33.32Stragusvasc: I'm sure. My raytracer of triangles reached a billion rays per second... while a CPU core does 20M per second at most
16:33.44Stragus(SSE optimized CPU code)
16:33.56vascmdtwenty[m], what's the amount of primitives in each scene?
16:34.33vascjust for curiosity's sake.
16:35.06vasci think there's a 'list' command in mged or something
16:35.25mdtwenty[m]goliath has 10499 primitives and havoc 2429
16:35.46vascpfew, it's still smaller at least.
16:35.58vascbut...
16:36.09StragusThere could be some ray hitting a bunch of aligned screws? :)
16:36.10mdtwenty[m]well the good news is that the boolean weaving doenst crash
16:36.49vascwell it might use an outrageous amount of memory.
16:37.10vascso perhaps Stragus will get his thing.
16:37.26vasc:-)
16:37.48vascthe havoc with 105 is ok i guess.
16:37.51vascbut 493
16:38.10vascthat's 16 double words
16:38.25vasci.e. cl_uint [16]
16:38.41mdtwenty[m]yeah i got 493 while rendering with the front view
16:39.09vasccan you compute the amount of memory that would take with that size of bitvector?
16:39.17vascthe whole segments array
16:39.39StragusWhy use the max depth for a ray though? Why not compute the sum of all rays, through a reduction kernel, if you are going to perform an identical trace right away?
16:40.08vascwe have a bitvector we use inside each ray's segment list
16:40.15Stragus(I still prefer dynamically allocated memory, but your way would work fine, except for the tracing-twice thing)
16:41.00vascwell
16:41.02vascit's like
16:41.06vascwe have a list of segments
16:41.11vascwhich gets computed into a list of partitions
16:41.44vascand then that gets evaluated
16:42.05StragusSo each ray computes how much storage it requires, it stores that number, and you reduce all these numbers to a grand total?
16:42.13vasceach segment only belongs in one object right? but the partitions can belong to more than one.
16:42.30vasclike the ray pierce one and exits the other. but it's the same partition solid space.
16:42.52vascyeah its kinda like that.
16:43.22vascbut that's only used to compute the amount of space we'll need.
16:43.30vascthe actual algorithm isn't just a reduction.
16:44.17StragusRight... but what I'm saying is that it doesn't matter if the "max depth" is 40000 due to a bunch of aligned screws somewhere
16:44.25StragusYou want the total for all rays
16:44.38vascmdtwenty[m], another thing we could do is dynamically allocate the bitvector, so rays with more segments would get larger bitvectors, but i wonder if that would complicate the code too much.
16:45.22vaschmm
16:47.59vascso it's max_partitions*sizeof(cl_partition_without the bitvector)+max_partitions*sizeof(cl_uint)*(493/32)
16:48.09vaschow much is that in bytes?
16:48.17vascmdtwenty[m]
16:48.44vascand this max_partitions is the total amount of partitions for all the rays.
16:48.53vascsum
16:49.48mdtwenty[m]one sec
17:03.16vaschmm
17:03.31vascperhaps this is not as a big of a deal as i thought
17:04.22vasc+struct cl_partition {
17:04.22vasc+    struct cl_seg inseg;
17:04.22vasc+    struct cl_hit inhit;
17:04.22vasc+    struct cl_seg outseg;
17:04.22vasc+    struct cl_hit outhit;
17:04.23vasc+    cl_uint segs;               /* 32-bit vector to represent the segments in the partition */
17:04.25vasc+};
17:04.30vascbut
17:04.35vascstruct cl_hit {
17:04.35vasc<PROTECTED>
17:04.35vasc<PROTECTED>
17:04.35vasc<PROTECTED>
17:04.37vasc<PROTECTED>
17:04.39vasc<PROTECTED>
17:04.41vasc};
17:04.43vascand
17:04.46vascstruct cl_seg {
17:04.47vasc<PROTECTED>
17:04.49vasc<PROTECTED>
17:04.51vasc<PROTECTED>
17:04.53vasc};
17:04.55vascso
17:04.57vascwho cares.
17:05.03*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
17:05.35vascit's like just a cl_hit has 8+8+8+2+1 words
17:05.39vascdouble words
17:05.57vasci.e. 27
17:06.25StragusThat cl_hit struct is kind of heavy, like 84 bytes
17:06.29vascand each partition has like 6 of those
17:07.10vascso using even 16 double words for the bitvector seems pathetic in comparison.
17:07.50vascstill i'm kinda interested to know how much memory the whole thing uses right now.
17:08.29vascStragus, it's much, much worse than that.
17:08.43vasccoz cl_double3's are ACTUALLY cl_double4s.
17:09.15vascit's an opencl thing.
17:09.40vascand then there's struct alignment
17:09.49vascwhich reminds me
17:09.58vascmdtwenty[m], instead of this:
17:10.22vasc+struct cl_partition {
17:10.22vasc+    struct cl_seg inseg;
17:10.22vasc+    struct cl_hit inhit;
17:10.22vasc+    struct cl_seg outseg;
17:10.22vasc+    struct cl_hit outhit;
17:10.23vasc+    cl_uint segs;               /* 32-bit vector to represent the segments in the partition */
17:10.24vasc+};
17:10.27vasctry this:
17:10.38vasc+struct cl_partition {
17:10.38vasc+    struct cl_seg inseg;
17:10.38vasc+    struct cl_seg outseg;
17:10.38vasc+    struct cl_hit inhit;
17:10.38vasc+    struct cl_hit outhit;
17:10.39vasc+    cl_uint segs;               /* 32-bit vector to represent the segments in the partition */
17:10.41vasc+};
17:10.46vascand see if it's sizeof() is smaller.
17:11.01StragusThat shouldn't make a difference, both cl_hit and cl_seg have the same alignment
17:11.08vasci hope so.
17:11.55StragusIf these cl_double3 waste memory, then perhaps it should be packed differently
17:11.58vascits the buildin cl_types that are an issue usually.
17:12.02vascbuiltin
17:12.45StragusAlthough frankly, this whole data storage scheme is very unfriendly to GPUs and SIMD
17:12.55vaschm
17:13.05vasconly because it isn't z-orderered.
17:13.09vascoh i see.
17:13.34vascwell
17:13.39StragusNo! Because you will have scattered loads/stores all over
17:13.48StragusAll memory transactions will be 8 times slower than necessary
17:14.10vascthe thing is you probably don't need the whole thing across all stages of the algorithm
17:14.20vascso you could fraction this
17:14.33vascand increase memory locality.
17:14.39StragusFor best performance, all threads of a warp/wavefront need to access consecutive memory addresses
17:14.44*** join/#brlcad merzo (~merzo@194.140.108.146)
17:15.01StragusSo you need some struct where  struct foo { float x[32]; float y[32]; etc. };
17:15.02vascits like i said, you don't need to whole thing.
17:15.07vasceven before that.
17:15.45vascyeah i know but if we minimize the size of the elements it ain't a big deal.
17:15.59vascthe problem is the structs are too fat right now.
17:16.20vascstill
17:16.35vascin comparison to the ANSI C code, it's incredibly memory coherent ya know?
17:16.40StragusNot a big deal? The stride between elements doesn't matter unless it's in the same cache lines
17:17.00StragusWell, these memory operations will be 8 times slower than if they were reorganized differently
17:17.14StragusThat may or may not be a bottleneck, you'll decide that
17:17.31vasceven with a cache?
17:17.34vasci'm not sure about that.
17:17.53vasci think the main issue is to have poor memory locality in accesses.
17:18.00vascrather than the access patterns themselves.
17:18.41StragusIt's not about the cache, it's about memory transactions
17:18.52vascmemory bank conflicts?
17:19.00StragusI am very sure about that, been doing CUDA for 8 years, and probably the biggest helper in #cuda...
17:19.16StragusBank conflicts are for shared memory
17:19.58vascwell the thing is
17:20.09vascif you're gonna need to access the rest of the struct in the same kernel
17:20.29vascit's all going to have to be loaded anyway.
17:20.30StragusPresumably, all threads of the same warp/wavefront will also access the rest of their structs, no?
17:21.15vascthat's the thing i said, i think we don't need to store everything in that struct in all the stages of the algorithm. it's just that currently we're slavishly following the way the existing ANSI C code is structured.
17:21.37vasclike
17:21.54StragusOkay! But it should still be designed so that consecutive threads access consecutive values in memory
17:22.02StragusYou don't want a stride between threads
17:23.08vasci'll give you an example. i thought about doing that in the intersections code.
17:23.29StragusConsecutive addresses is _the_ solution that is fast on all GPUs from all vendors, for all generations. Beyond that, there are particularities if the accesses are shuffled, out of order, with gaps between chunks of 128 bytes, etc.
17:23.33vascwell it turns out each kernel still has so many branches. a lot of threads will be idling and it's awfully low performance.
17:23.46vascthe GPU isn't maxed out.
17:23.57StragusAll right. But the threads that are active would still access a bunch of packed addresses
17:24.09vascno it's actually terrible.
17:24.33vascimagine one thread is doing a quadric like a sphere, and the other is doing a thorus intersection.
17:24.55StragusIndeed, paths should be merged as much as possible. Coherent rays can help a lot with that
17:25.14vascwell i thought about that. that actually kind of happens as it is.
17:25.28vascsince i'm using a thread block.
17:25.30vascbut
17:25.36StragusIf there are some common operations between spheres and thorus, like storing data (memory transactions), they should be merged together
17:25.46vasci think the best thing would be to reorder the intersection calculations.
17:25.47StragusAs little code as possible should be specific to branches
17:25.57StragusThat's possible, yes
17:26.21vasclike group the ones that use the same kernel solver together.
17:27.18vascbut the whole existing ANSI C code is more built to minimize the amount of operations than either memory consumption, or maximize memory coherency
17:27.18StragusIt's possible to have warp-wide votes to decide how many threads need to perform operation X, before deciding to do it with a bunch of threads
17:27.38vascor minimize branches
17:27.38StragusBut these aren't as critical issues as properly organizing memory. Reshuffling memory implies rewriting a lot of code, so it must be done early
17:27.59StragusRight, it's very different to optimize for scalar execution and for wide parallelism
17:28.09vascits not just that
17:28.16vascit's optimized for 1980s machines
17:28.20StragusOh I see, yes
17:28.32StragusMemory was fast, ALUs were slow. And now it's the other way around
17:28.35vascyep+
17:31.01vascso mdtwenty[m] any luck with that?
17:33.19mdtwenty[m]sent a long message: mdtwenty[m]_2017-06-23_17:33:18.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/hVZtHbkIpDKOvbklzQAQwlpz>
17:33.39vascok
17:33.47vascwhat about the memory size of the whole thing?
17:35.35vasc<vasc> hmm
17:35.36vasc<vasc> so it's max_partitions*sizeof(cl_partition_without the bitvector)+max_partitions*sizeof(cl_uint)*(493/32)
17:35.36vasc<vasc> how much is that in bytes?
17:35.36vasc<vasc> mdtwenty[m]
17:35.36vasc<vasc> and this max_partitions is the total amount of partitions for all the rays.
17:35.38vasc<vasc> sum
17:35.41mdtwenty[m]i got 2337015024
17:35.55mdtwenty[m]for the goliath that has 493 depth
17:36.35vasc2 GB?!
17:37.04vascok, how much is  max_partitions*sizeof(cl_partition_without the bitvector) alone?
17:37.39mdtwenty[m]compiling
17:39.06mdtwenty[m]2 179 756 800
17:39.49vascalso i wanna see the code for bool_Eval
17:39.59vascso the bitvectors aren't the real problem
17:40.16vascsince they use a "mere" 200 MB or less.
17:40.31vascok i think i got the idea
17:40.36vasc+struct cl_partition {
17:40.36vasc+    struct cl_seg inseg;
17:40.36vasc+    struct cl_hit inhit;
17:40.36vasc+    struct cl_seg outseg;
17:40.37vasc+    struct cl_hit outhit;
17:40.37vasc+    cl_uint segs;               /* 32-bit vector to represent the segments in the partition */
17:40.39vasc+};
17:40.41vasc+
17:40.53vascinstead of storing copies of the cl_segs, why not use indexes instead?
17:41.51mdtwenty[m]yes i think that it would work
17:43.40vasc((8*4*3+8+4)*2+4)*2 vs 4*2
17:43.45vasc440 vs 8
17:43.56vascthat should shrink things down
17:47.10vascso you have the code for bool_eval so i can look at it? i kind of want to understand which data in the partitions will get accessed in rt_boolfinal and rendering.
17:49.30mdtwenty[m]posted a file: ocl_bool_eval.patch (51KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/SFtMrGVveJAkLiBFABODKZMf>
17:49.40mdtwenty[m]this should be it
17:51.27vascok
17:51.40mdtwenty[m]i think that only the segments in the partition are relevant for boolean evaluation and shading
17:51.48vascrt_boolfinal seems to hammer a partition's inhit/outhit .hit_hist's over and over.
17:52.01vasc.hit_dist
17:52.11vascand then it computes segment regions
17:54.50vascin a later optimization we may want to simplify the partition structures.
17:55.03vascstruct cl_hit {
17:55.03vasc<PROTECTED>
17:55.03vasc<PROTECTED>
17:55.03vasc<PROTECTED>
17:55.03vasc<PROTECTED>
17:55.04vasc<PROTECTED>
17:55.06vasc};
17:55.15vascof all of this, it looks as if rt_boolfinal only accesses the hit_dist.
17:55.31vasci think the rest is only accessed in the final rendering stages.
17:56.14vascbut for now, just not storing the whole cl_segs in the cl_partitions should be enough.
17:57.21StragusEh, still keep in mind that repacking of hits in structs of arrays of 32 or 64
17:58.09vascwell the current code is horrible in several ways.
17:58.25vascjust the amount of memory copies going on is kind of insane.
17:58.34vasci'm surprised it's as fast as it is.
17:58.44StragusHow "fast" is fast? :)
17:59.11StragusThe reference CPU code is also abysmally slow, so it's not a great point of comparison
17:59.44vascmdtwenty[m], after you use indexes instead of storing the whole cl_segs, test goliath and havok again. tell me the time it takes and if it crashes or not.
18:00.00vascStragus, well it's what we have.
18:00.26vascmdtwenty[m], once you get that working, it's time to work on rt_boolfinal
18:00.54vascmdtwenty[m], oh and tell me how much memory it uses to store the partitions now vs what it used before.
18:01.05vascwith the indexes.
18:01.10mdtwenty[m]and what about the bitvector for now?
18:01.25vascyes, use the dynamic bitvector too
18:01.35vasci paste the code above? did you get it?
18:01.37vascpasted
18:01.59vasc<vasc> ok found it
18:01.59vasc<vasc> == host
18:01.59vasc<vasc> cl_uint ND = N/WORD_BITS + 1;
18:01.59vasc<vasc> mD = clCreateBuffer(gpuCtx, CL_MEM_READ_WRITE, sizeof(cl_uint) * ND, NULL, NULL);
18:01.59vasc<vasc> == device
18:02.00vasc<vasc> inline uint bindex(const uint b) {
18:02.02vasc<vasc>   return (b >> 5);
18:02.04vasc<vasc> }
18:02.06vasc<vasc> inline uint bmask(const uint b) {
18:02.08vasc<vasc>   return (1 << (b & 31));
18:02.10vasc<vasc> }
18:02.12vasc<vasc> inline uint isset(__global uint *bitset, const uint b) {
18:02.14vasc<vasc>   return (bitset[bindex(b)] & bmask(b));
18:02.16vasc<vasc> }
18:02.18vasc<vasc> inline uint clr(__global uint *bitset, const uint b) {
18:02.20vasc<vasc>   return (bitset[bindex(b)] &= ~bmask(b));
18:02.22vasc<vasc> }
18:02.24vasc<vasc> inline uint set(__global uint *bitset, const uint b) {
18:02.26vasc<vasc>   return (bitset[bindex(b)] |= bmask(b));
18:02.28vasc<vasc> }
18:02.30vasc<vasc> -
18:02.32vasc<vasc> this is my code, so i give you permission to it for any purpose.
18:02.34vasc<vasc> where WORD_BITS is 32 since 'D' is an array of cl_uints
18:02.35vasc<vasc> and N is the amount of bits you want the bitvector to have.
18:03.10vascbasically you have a cl_uint array per bitvector
18:03.32vascand you an use the isset, clr, or set functions to twiddle the bits.
18:03.39vascor query them.
18:04.48vascfor a start you can just use a cl_uint segs[16]; or whatever
18:04.59vascbut eventually you want to dynamically determine the size of this
18:05.39vascthe quick and dirty way to do it, is basically to pass it as a #define before the kernels are compiled.
18:06.07vascbut don't do that.
18:06.28vascwe'll probably need to optimize this some other way. but without more tests, it's hard to determine the appropriate solution,.
18:07.05StragusThat bitvector is to determine entry/exit status through solids?
18:07.15vascno
18:07.29vascit states which segments are within a partition
18:07.43vascit's per ray
18:08.01vascwe could do this some other way though
18:08.01StragusOkay. I guess I'm not familiar enough with the terminology used by the BRL-CAD raytracer
18:08.27vascif the bitvector is too sparse, we would probably be better off with using a list, like the current code already does.
18:09.11StragusWithout knowing what the bitvector was, that was my thought
18:10.31vascwell.
18:10.47vasci thought there would be less depth complexity in the average scene than ther actually is.
18:10.50vascmy mistake.
18:11.35vasca typical game scene has like 3 depth complexity.
18:12.05vascin here we don't cull stuff.
18:12.28vasci thought 32  was enough. so much for that.
18:12.38*** join/#brlcad teepee (~teepee@unaffiliated/teepee)
18:13.28vasci know there are hard limits in the amount of intersections per ray on triangle meshes in the current code for example.
18:15.59vaschttps://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/primitives/bot/tie.c
18:16.06vasc<PROTECTED>
18:17.32vascmdtwenty[m], if the bitvector is too slow on the goliath scene, we'll have to use lists again...
18:18.29mdtwenty[m]ok, i will change the bool weave to use the indexes for segments intead of the segs and will test
18:18.35vascok
18:22.20vaschm
18:23.00vascso this is what the ANSI C code does for bool_eval of solids.
18:23.02vasccase OP_SOLID:
18:23.02vasc<PROTECTED>
18:23.02vascregister struct soltab *seek_stp = treep->tr_a.tu_stp;
18:23.02vascregister struct seg **segpp;
18:23.02vascfor (BU_PTBL_FOR(segpp, (struct seg **), &partp->pt_seglist)) {
18:23.03vasc<PROTECTED>
18:23.05vascret = 1;
18:23.07vascgoto pop;
18:23.09vasc<PROTECTED>
18:23.11vasc}
18:23.13vascret = 0;
18:23.15vasc<PROTECTED>
18:23.17vasc<PROTECTED>
18:27.39vascso
18:28.00vascyou need to know if a partition has a solid in it
18:31.31mdtwenty[m]a solid?
18:33.43vasca solid is basically a primitive object.
18:33.54vasclike a sphere.
18:34.03vascin brlcad parlance.
18:35.08vasca solid object.
18:39.01vasci'll go jog for a while. should be back in 30-45 mins
18:39.56mdtwenty[m]Ok :) i will also take a break to get dinner
19:04.28*** join/#brlcad DaRock (~Thunderbi@mail.unitedinsong.com.au)
20:17.32vasc.
20:38.16mdtwenty[m]so i changed the struct partition and it is working fine.. i am working on the dynamic bit vector right now
20:39.35vascgood. make sure to make a backup. :-)
20:40.12vascyou'll have to initialize the data though
20:40.30vascprolly the easiest way is to bzero the memory before using it.
21:03.27mdtwenty[m]ok i will have to leave the house for a bit and probably will only get back to this tomorrow morning
21:05.17mdtwenty[m]i will notify you once its done
21:07.27vascok
21:08.42vascsee you later then!

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.