| 00:00.00 | Stragus | Depends how it's done |
| 00:00.35 | vasc | well only way to know is to do it |
| 00:00.41 | vasc | it its too slow i'll think of something else |
| 00:00.59 | Stragus | It will be twice as slow as it should be |
| 00:01.13 | Stragus | That would qualify as "too slow" for me :p |
| 00:01.14 | vasc | if i could estimate a reasonable upper bound it work too |
| 00:01.24 | vasc | it sounds like that but sometimes its not as simple as that |
| 00:01.41 | Stragus | There are many, many ways to approach the problem |
| 00:01.43 | vasc | i've had experience with grid algorithms which use counting to determine size before doing the set and the code is faster |
| 00:02.02 | vasc | the working set of the data is smaller |
| 00:02.03 | Stragus | You could use X segments per ray, flag these rays for partial traversal, count how many extra segments they need, allocate, then finish the ray |
| 00:02.27 | Stragus | Or you could allocate on the fly the missing segments with multiple "fat buffers" with atomic counters (not just one counter, use many) |
| 00:02.45 | vasc | i'm going to have dozens of threads |
| 00:02.48 | vasc | or hundreds |
| 00:02.56 | vasc | more like hundreds |
| 00:03.08 | Stragus | Uh. If it's OpenCL/CUDA, you should have thousands |
| 00:03.13 | vasc | well |
| 00:03.15 | Stragus | Like > 10000 |
| 00:03.20 | vasc | my gpu has like 1024 i think |
| 00:03.32 | vasc | <PROTECTED> |
| 00:03.45 | Stragus | That's not the count of cores/lanes |
| 00:04.04 | Stragus | A GPU has multiple processing units, and each processing units can handle so many threads simultaneously |
| 00:04.18 | vasc | but the max work group size is the max |
| 00:04.24 | Stragus | It can handle more threads than it has cores, because GPUs hide memory latency by switching to different threads |
| 00:04.37 | Stragus | You use many "work groups", what we call blocks in CUDA |
| 00:04.40 | vasc | yeah |
| 00:04.56 | Stragus | Bottom line, *always* launch more than 10000 threads |
| 00:05.04 | Stragus | Heck, launch a million if you can :) |
| 00:05.08 | vasc | sure but *concurrently* its not gonna be more than 1024 |
| 00:05.24 | vasc | which is what matters for the locks |
| 00:05.24 | Stragus | This is 1024 threads for each SMM |
| 00:05.28 | Stragus | My GPU has 16 SMM |
| 00:05.37 | vasc | nah |
| 00:06.04 | Stragus | A "work group" (block) isn't shared across multiple processing units |
| 00:07.59 | Stragus | Also, when a thread is done processing, you want the GPU to already have more work at hand ready to go |
| 00:08.08 | vasc | yeah |
| 00:08.14 | Stragus | Seriously, you want more than 10000 threads, this is pretty much a minimum |
| 00:08.24 | vasc | i'm going to have one per pixel |
| 00:08.29 | Stragus | I frequently launch thread counts in the millions |
| 00:08.36 | Stragus | Good |
| 00:09.25 | vasc | it can be a problem though |
| 00:09.51 | vasc | if the block size is too big and not all threads finish at the same time the GPU utilization rate can be crap |
| 00:10.09 | vasc | i'll worry about that later |
| 00:10.15 | Stragus | I'm not following |
| 00:10.22 | Stragus | The GPU will work as fast as it can until all threads are done |
| 00:10.36 | vasc | lets say i split the image to be renderer in blocks with 16x16 pixels |
| 00:10.54 | Stragus | Except of course, that groups of 32 threads run synchroneously, so a group of 32 threads can only be "done" (freeing computing resources) when all 32 threads are fully done |
| 00:10.55 | vasc | but one of those pixels takes like 10x more time to process than the others |
| 00:11.00 | vasc | yeah |
| 00:11.01 | Stragus | Indeed |
| 00:11.29 | Stragus | If that's a frequent occurence, you can detect such cases and have the other 31 threads grab more work from some global buffer |
| 00:11.34 | Stragus | That's a headache though |
| 00:11.42 | vasc | yeah work stealing. that's an option people use. |
| 00:12.17 | Stragus | Generally, for raytracing, a group of primary rays (pixels) will be fairly coherent for processing |
| 00:12.23 | Stragus | It's not worth the trouble for primary rays |
| 00:12.38 | vasc | yeah most of the issue will be along edges and things like that |
| 00:12.49 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 00:13.40 | Stragus | It's also not worth the trouble because if you grab more work, memory loads will become incoherent, losing memory coalescing |
| 00:13.40 | Stragus | So your memory loads take longuer, and if that was the bottleneck in the first place, you don't gain much and with overhead |
| 00:13.40 | vasc | yeah this is an issue too |
| 00:14.22 | vasc | so another idea is if you can estimate the time each pixel will take and the space it traverses then you can use then to roughly sort rays. |
| 00:14.34 | vasc | before rendering. |
| 00:14.44 | Stragus | What kind of rays do you want to sort? Bouncing rays? |
| 00:14.58 | vasc | this it will be mostly useful for secondaries yes. |
| 00:15.14 | Stragus | True sorting of rays imply scattered writes which is *terrible*, but there are other ways |
| 00:15.37 | Stragus | For example, from a group of 32 primary rays, you can pick 32 bouncing rays with roughly the same direction and process them together |
| 00:15.58 | Stragus | So the origin and direction will be similar with little overhead |
| 00:16.08 | vasc | not necessarily |
| 00:16.16 | vasc | imagine your rays hit a sphere |
| 00:16.25 | vasc | they will diverge |
| 00:16.52 | Stragus | I'm assuming you launch many bouncing rays per primary hit, and you can quickly pick ones with roughly similar directions |
| 00:17.04 | Stragus | But each case is different. Just don't even try sorting with scattered writes :) |
| 00:17.04 | vasc | in that case sure |
| 00:17.13 | vasc | actually some people do that |
| 00:17.21 | vasc | and claim its better than not sorting at all |
| 00:18.08 | vasc | i'm not going into that until i get the basics working |
| 00:18.15 | Stragus | I have explored that stuff, it all depends how your data is organized and if you have tricks to make a rough sort that will statistically be somehwat coherent at a low cost |
| 00:18.23 | vasc | there's all sorts of issues |
| 00:18.27 | Stragus | (I wrote a high performance CUDA raytracer by the way) |
| 00:18.34 | vasc | cool |
| 00:19.00 | vasc | it is publically available? |
| 00:19.24 | vasc | publicly |
| 00:19.49 | Stragus | A first version was put on sourceforge and never (?) updated |
| 00:20.00 | Stragus | You can google "Rayforce" |
| 00:24.20 | vasc | i saw the webpage. it says it doesn't use bsps and stuff but isn't very explicit in the technique |
| 00:24.34 | vasc | the performance seems good |
| 00:24.57 | Stragus | It was the fastest raytracer when we presented at the Nvidia conference |
| 00:25.11 | Stragus | But the preparation time is terrible :p (single threaded, very computionally intensive) |
| 00:25.24 | Stragus | And I haven't followed developments, so others could be faster |
| 00:26.02 | vasc | you need to build some acceleration structure and that is single-threaded? |
| 00:26.26 | vasc | but the rendering and moving the camera is fast? |
| 00:26.35 | Stragus | Yup, pretty much |
| 00:26.41 | vasc | that's typical |
| 00:26.49 | Stragus | The scene preparation could be much faster, it just wasn't an issue |
| 00:27.02 | vasc | there's a lot of work in last 5-7 years on fast build acceleration structure |
| 00:27.16 | vasc | it typically can take tens or hundreds of ms now to build one |
| 00:27.47 | vasc | http://web.ist.utl.pt/~vasco.costa/uploads/Main/cgi2015.pdf |
| 00:27.56 | vasc | this is a short paper i made on fast build grids on gpus |
| 00:28.29 | vasc | it can build a grid for the san miguel scene at over 25hz |
| 00:28.29 | Stragus | Cool. Yes, I know there has been a lot of work on making the preparation fast |
| 00:28.45 | Stragus | i went completely the other way. How fast can raytracing be, even if you need minutes to prepare? :) |
| 00:28.52 | vasc | this is good too |
| 00:29.07 | vasc | there were some papers decades back on what they called 'constant time ray tracing' |
| 00:29.11 | Stragus | Since you can build and cache the whole graph, it's not always an issue |
| 00:29.36 | vasc | i haven't seen a lot since |
| 00:29.49 | vasc | do you have some paper on this or slides? |
| 00:30.18 | Stragus | I don't personally have this... A colleage wrote some paper on a tiny piece of the work |
| 00:30.30 | vasc | ah |
| 00:30.33 | Stragus | I agreed to help writing a paper, but they wanted to split the information into 5-6 papers or something |
| 00:30.35 | Stragus | sighs |
| 00:30.36 | vasc | well i'll look at the code when i have time |
| 00:30.43 | Stragus | I'm not from academia :p |
| 00:30.58 | vasc | well it can be pretty hard to publish system papers |
| 00:31.04 | vasc | its easier to publish algorithm papers |
| 00:31.15 | vasc | so its probably like a paper per main algorithm what they wanted |
| 00:31.40 | Stragus | I'm generally not interested to write, publish or read papers |
| 00:32.24 | vasc | well its a different way to transmit knowledge that's all |
| 00:32.58 | vasc | i did my undergraduate, then went to work in the private sector, then came back to do my phd |
| 00:33.03 | vasc | so i've seen both sides |
| 00:34.07 | Stragus | There's just so much... garbage in papers, with all of academia pressured to write as many papers as they can, even when they have absolutely nothing to say |
| 00:34.12 | vasc | and its true that there's nothing truer than the source code |
| 00:34.50 | vasc | that happens |
| 00:35.07 | vasc | but you usually won't get published anywhere good with something like that |
| 00:35.35 | vasc | it doesn't help that you get performance evaluated on numbers of papers published |
| 00:35.49 | vasc | this is a problem with any of those kinds of performance evaluation schemes |
| 00:36.44 | Notify | 03BRL-CAD Wiki:JackySandman1 * 0 /wiki/User:JackySandman1: |
| 00:37.00 | Stragus | Yup. I have glanced over too many worthless papers to generally bother anymore |
| 00:37.25 | Stragus | While the "good idea", if there's one at all, can often be resumed in two lines |
| 00:37.33 | vasc | yeah |
| 00:37.48 | Notify | 03BRL-CAD Wiki:JackySandman1 * 8531 /wiki/Documentation: Undo revision 8302 by [[Special:Contributions/Sean|Sean]] ([[User talk:Sean|talk]]) |
| 00:37.59 | vasc | but you need to prove it works so you need tests and test results and so on |
| 00:38.52 | Stragus | I'll let others take care of that :p |
| 00:39.10 | Notify | 03BRL-CAD Wiki:JackySandman1 * 0 /wiki/File:Picture.jpg: |
| 01:00.55 | vasc | the traversal code is a bit of a mess |
| 01:00.58 | vasc | i'll continue tomorrow |
| 01:01.00 | vasc | good night |
| 01:15.16 | *** join/#brlcad LordOfBikes_ (~armin@dslb-092-074-231-184.092.074.pools.vodafone-ip.de) | |
| 02:24.36 | Notify | 03BRL-CAD Wiki:59.91.113.247 * 8533 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 02:31.11 | Notify | 03BRL-CAD Wiki:59.91.113.247 * 8534 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 02:35.35 | Notify | 03BRL-CAD Wiki:Sean * 8535 /wiki/Documentation: Reverted edits by [[Special:Contributions/JackySandman1|JackySandman1]] ([[User talk:JackySandman1|talk]]) to last revision by [[User:Sean|Sean]] |
| 02:35.53 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/User:JackySandman1: Inserting nonsense/gibberish into pages |
| 02:36.28 | *** join/#brlcad cardinot (~cardinot@unaffiliated/cardinot) | |
| 02:36.38 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/Alexander_Tatarnikov_(diezel_sun): Spam: spam |
| 02:37.00 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/File:Picture.jpg: |
| 02:37.28 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/File:Picture.jpg: |
| 03:19.43 | *** join/#brlcad Gurwinder (3b5b71f7@gateway/web/freenode/ip.59.91.113.247) | |
| 03:25.43 | Notify | 03BRL-CAD:brlcad * 65159 brlcad/trunk/src/other/openNURBS/opennurbs_system.h: add support for compiling with the AIX 7.1 compiler/linker |
| 04:45.36 | *** join/#brlcad Milinda (c0f80842@gateway/web/freenode/ip.192.248.8.66) | |
| 04:45.41 | Milinda | Anyone know a good tutorial to create a brl-cad display manager instance in qt ? |
| 05:30.59 | *** join/#brlcad DarkCalf (~DarkCalf@64.185.232.90) | |
| 05:34.47 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-anzpkzgrsvgdekfc) | |
| 06:03.06 | Notify | 03BRL-CAD:brlcad * 65160 brlcad/trunk/src/librt/screened_poisson.cpp: quell dir1 being set but unused by using it. warnings-as-errors should probably be enabled for librt c++... more has crept in. |
| 06:13.51 | Notify | 03BRL-CAD:brlcad * 65161 brlcad/trunk/src/libbu/fgets.c: per manpage, buffer contents are supposed to remain unchanged if eof is encountered before we read |
| 06:23.33 | Notify | 03BRL-CAD:brlcad * 65162 brlcad/trunk/src/libbu/vls.c: it's possible for bu_fgets to return an empty string, so make sure we don't try to index -1 |
| 06:27.40 | *** join/#brlcad Gurwinder (caa43575@gateway/web/freenode/ip.202.164.53.117) | |
| 06:47.36 | dracarys983 | brlcad, starseeker, ``Erik: I have to study raytracing in detail for my Honors work and it seems we've shifted to PBRT for the experimentation and extension. How is the book "Physically Based Rendering" for the task? |
| 06:51.51 | Notify | 03BRL-CAD:brlcad * 65163 brlcad/trunk/src/mged/mged.c: make sure we don't try to index into an invalid -1 address if the prompt happens to be empty |
| 07:00.42 | *** join/#brlcad andromeda-galaxy (~andromeda@108-225-17-54.lightspeed.sntcca.sbcglobal.net) | |
| 08:17.07 | Notify | 03BRL-CAD Wiki:Andrei.ilinca24 * 8536 /wiki/User:Andrei.ilinca24/logs: /* Coding Period */ |
| 09:06.09 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) | |
| 09:37.42 | *** join/#brlcad sofat (~sofat@202.164.53.117) | |
| 09:39.22 | sofat | starseeker, hello |
| 09:40.04 | sofat | i want to add new xsl stylesheet in brlcad-build system how i do this ? which code i need to edit. |
| 11:30.54 | ``Erik | msvc is primarily a C++ compiler, not a C compiler... I doubt they actually fully support c89, just a common subset (and iirc, they introduce c++isms in violation of c89) |
| 11:31.32 | ``Erik | woops, brlcad already said that :) |
| 12:08.53 | Notify | 03BRL-CAD Wiki:Muslattoggariso * 0 /wiki/File:Picrure.jpg: Picture, diezelsun. |
| 12:10.22 | Notify | 03BRL-CAD Wiki:Muslattoggariso * 8539 /wiki/Talk:Alexander_Tatarnikov_(diezel_sun): Created page with "Here and so it is necessary to expertly create pictures in graphic programs." |
| 12:11.48 | Notify | 03BRL-CAD Wiki:Muslattoggariso * 8540 /wiki/Alexander_Tatarnikov_(diezel_sun): |
| 13:11.04 | Notify | 03BRL-CAD:n_reed * 65164 (svn:mergeinfo ## -3,4 +3,4 ## and 6 others): record revisions merged to trunkProperty Changed:----------------brlcad/branches/brep-debug/brlcad/branches/brep-debug/src/libged/polyclip.cpp |
| 13:23.33 | Notify | 03BRL-CAD:n_reed * 65165 (brlcad/branches/brep-debug/AUTHORS brlcad/branches/brep-debug/BUGS and 1184 others): sync from trunk |
| 13:51.17 | Notify | 03BRL-CAD:n_reed * 65166 (svn:mergeinfo ## -1,5 +1,5 ## and 7 others): record merge revisionProperty Changed:----------------brlcad/trunk/brlcad/trunk/src/libged/polyclip.cpp |
| 14:38.44 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 16:23.33 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8541 /wiki/User:MeShubham99/GSoc15/log_developmen: |
| 16:24.32 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8542 /wiki/User:MeShubham99/GSoc15/log_developmen: |
| 16:34.37 | *** join/#brlcad d3r1ck (~root@195.24.220.134) | |
| 16:34.58 | d3r1ck | Ch3ck: he is not around |
| 16:35.03 | d3r1ck | hello all |
| 16:36.22 | *** part/#brlcad d3r1ck (~root@195.24.220.134) | |
| 16:36.36 | *** join/#brlcad snowlove (~albertcod@1.39.35.154) | |
| 16:54.10 | Notify | 03BRL-CAD Wiki:59.91.114.217 * 8543 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 17:20.25 | *** join/#brlcad snowlove (~albertcod@1.39.32.65) | |
| 17:24.23 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8544 /wiki/User:MeShubham99/GSoc15/log_developmen: |
| 17:30.43 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8545 /wiki/User:MeShubham99/GSoc15/OGV_production_ready_plan: |
| 17:47.15 | *** join/#brlcad terrywen (~twen6@pool-71-97-144-189.bltmmd.fios.verizon.net) | |
| 17:48.19 | *** join/#brlcad andrei_il (~andrei@109.100.128.78) | |
| 17:55.56 | ``Erik | mm, full screen terminal with no decorations, 'snice. why haven't I done this before? O.o |
| 18:24.45 | *** join/#brlcad LordOfBikes (~armin@dslb-092-074-231-184.092.074.pools.vodafone-ip.de) | |
| 18:34.14 | Notify | 03BRL-CAD:ejno * 65167 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: refactor find_ccone_cutout() and implement find_csphere_cutout() |
| 18:42.00 | Notify | 03BRL-CAD:ejno * 65168 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: make db_i's const |
| 18:56.09 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/File:Picrure.jpg: spam |
| 18:56.23 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/User:Muslattoggariso: Spamming links to external sites |
| 18:56.56 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/File:Picrure.jpg: |
| 18:57.54 | Notify | 03BRL-CAD Wiki:Sean * 0 /wiki/Talk:Alexander_Tatarnikov_(diezel_sun): spam |
| 19:11.58 | Notify | 03BRL-CAD Wiki:202.164.45.204 * 8546 /wiki/User:Hiteshsofat/GSoc15/log_developmen: |
| 19:12.59 | *** join/#brlcad sofat (~sofat@202.164.45.204) | |
| 19:13.15 | sofat | brlcad, hello |
| 19:15.00 | sofat | I am done the work of worspress xsl stylesheet noe i want to add this xsl file into brlcad buid system so how i do this ? I want run this xsl on all document and convert into wordpress php and store into another directory . |
| 19:16.12 | brlcad | dracarys983: it's a good book, written specifically for teaching ray tracing concepts |
| 19:16.45 | brlcad | sofat: what searching have you done to figure this out on your own |
| 19:17.02 | sofat | s/noe/now |
| 19:17.48 | brlcad | you've asked the question 3 times :) |
| 19:19.46 | brlcad | sofat: what searching have you done? |
| 19:19.53 | sofat | yes but i want to know how i use this file in your brlcad building so now want konw which file i need to edit for this. |
| 19:19.59 | brlcad | I know what you want |
| 19:20.05 | sofat | s/konw/know |
| 19:20.18 | brlcad | I'm asking what have you done to try and figure it out on your own? |
| 19:21.06 | Notify | 03BRL-CAD:carlmoore * 65169 brlcad/trunk/src/util/bwmod.c: remove initialization of c, because it's immediately set in a 'while' statement |
| 19:22.44 | brlcad | it's nobody's job to simply answer your questions -- the mentors are to help when you are stuck (which requires understanding why you are stuck), to help you stay motivated (which requires encouragement and testing), and help YOU find the answers you're looking for (which requires teaching you how to learn, not simply answer questions) |
| 19:22.46 | sofat | yes i am checking some .cmake files but i am not got right direction |
| 19:22.58 | brlcad | which files? |
| 19:23.25 | sofat | CMakeList.txt files |
| 19:24.01 | *** join/#brlcad CNCProShane (~cncpro@70-88-111-205-Michigan.hfc.comcastbusiness.net) | |
| 19:24.35 | brlcad | ... which CMakeList.txt files? there are thousands in the tree |
| 19:26.38 | sofat | doc/docbook/CMakeLists.txt |
| 19:26.54 | brlcad | excellent, that's a great place to start |
| 19:27.07 | sofat | doc/docbook/article/CMakeLists.txt |
| 19:27.25 | brlcad | also appropriate as that one even identifies a stylesheet |
| 19:28.46 | brlcad | do you notice in that first file how the logic is wrapped in various BRLCAD_EXTRADOCS_* variables? |
| 19:28.55 | brlcad | e.g., BRLCAD_EXTRADOCS_HTML |
| 19:29.57 | brlcad | yes? |
| 19:30.04 | brlcad | no? |
| 19:30.20 | brlcad | *crickets* |
| 19:30.30 | sofat | yes |
| 19:30.37 | brlcad | okay, great |
| 19:30.57 | brlcad | so what you essentially need to do is add your own BRLCAD_EXTRADOCS_* logic |
| 19:31.23 | brlcad | probably BRLCAD_EXTRADOCS_WORDPRESS |
| 19:31.45 | brlcad | and fortunately, the BRLCAD_EXTRADOCS_HTML code is almost exactly what you need already |
| 19:32.04 | brlcad | so start there, search the tree for that symbol and add your own for wordpress |
| 19:32.08 | sofat | ok |
| 19:32.27 | brlcad | grep -r BRLCAD_EXTRADOCS_HTML . |
| 19:32.58 | brlcad | you'll basically find a little bit of logic in the top CMakeLists.txt file, a little in misc/CMake, and a lot in the doc/docbook subdirectories |
| 19:33.38 | brlcad | some day starseeker might revisit his promise to clean that all up so it's not so sprawling and redundant, but that's your pattern for now ;) |
| 19:34.24 | sofat | ok i will check |
| 19:55.48 | *** join/#brlcad cox (~quassel@188.226.208.53) | |
| 19:56.09 | *** join/#brlcad terrywen (~twen6@pool-71-97-144-189.bltmmd.fios.verizon.net) | |
| 20:03.50 | Notify | 03BRL-CAD:carlmoore * 65170 brlcad/trunk/doc/docbook/system/man1/en/bwmod.xml: redo parts of the bwmod man page |
| 20:11.20 | Notify | 03BRL-CAD:carlmoore * 65171 brlcad/trunk/doc/docbook/system/man1/en/bwstat.xml: modify the remark about square root |
| 20:44.22 | Notify | 03BRL-CAD Wiki:Andrei.ilinca24 * 8547 /wiki/User:Andrei.ilinca24/logs: /* Coding Period */ |
| 20:45.14 | dracarys983 | brlcad: Cool. Thanks :) |
| 21:47.31 | Notify | 03BRL-CAD Wiki:Konrado DJ * 8548 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 2 JUNE 2015 */ |
| 21:50.05 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) | |
| 22:21.11 | Notify | 03BRL-CAD:carlmoore * 65172 brlcad/trunk/doc/docbook/system/man1/en/bwmod.xml: put 'bwstat' in boldface, and fix the line breaks near it |
| 22:29.30 | Notify | 03BRL-CAD:ejno * 65173 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: refactoring |
| 22:34.00 | Notify | 03BRL-CAD:ejno * 65174 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: disable comb_representable() for now |
| 22:36.14 | Notify | 03BRL-CAD:ejno * 65175 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: formatting |