OpenCL Raytracing · Google Summer of Code

Hi, I've submitted a patch for CLINE primitive here https://sourceforge.net/p/brlcad/patches/541/ . Please review. I've tested it locally and it is building without error. Also, I saw a bunch of unmerged patches from 2 years back, are they wrong?

Rishabh Suthar (Mar 30 2020 at 16:20):

Hi @Sean , I've submitted a proposal. Please review and let me know if I can include anything else in it.

Daniel Rossberg (Mar 30 2020 at 16:49):

Hi @Rishabh Suthar, I had just a look at your proposal. It is a bit short, but this isn't the biggest problem. There is a reason why these primitives aren't yet available with OpenCL. If I understood it right, the main problem is their dynamic size. You should say something about how you plan to overcome this issue.

Rishabh Suthar (Mar 30 2020 at 20:30):

Thanks for the input @Daniel Rossberg . Given tomorrow's deadline for submitting proposal, I'll try to address the issue in it or else will just acknowledge in it while I'll keep working on it later.

Sean (Mar 31 2020 at 05:50):

Old patches are a combination of mixed priority and other issues that prevented merging the patch (like untested or broken compilation or other problems). They also take considerable time to review and integrate, so they often sit. It doesn't typically imply anything.

Sean (Mar 31 2020 at 05:52):

Like Daniel said, the biggest issue @Rishabh Suthar is a lack of detail. Try to add as much as possible in the time remaining, keep an editable draft handy for discussion.

Sean (Mar 31 2020 at 06:26):

Also, don't forget to submit a final before the deadline, but detail, detail, detail regardless. Did you test your patch? Can you show it working?

Rishabh Suthar (Mar 31 2020 at 16:16):

Hi, I didn't get much time to look into this. I've included as much details in the proposal as possible for now and will keep looking into issues later. Hope that is fine.

Sean (Apr 21 2020 at 17:40):

@Rishabh Suthar Have you had a chance to sort out any more progress on your proposal or code?

Rishabh Suthar (Apr 22 2020 at 15:35):

Hi @Sean , I'm currently getting myself familiarised with the mged commands and the primitives getting to know how they work and process.

Rishabh Suthar (May 05 2020 at 05:21):

Hi team, thank you for choosing me as one of the interns. It means a lot to me. Eagerly looking forward to making successful and effective contributions to this community. :)

Sean (May 05 2020 at 05:58):

@Rishabh Suthar thank you for all your efforts on the proposal. few applicants actually followed all of the application criteria this year, so it was good to see you step up and follow through with discussion too. open source is all about communication.

on that note, GSoC is different from an internship! internships come and go. this is hopefully the beginning of something new and interesting that you'll want to continue with well beyond GSoC, even beyond employment opportunities. it's the open source way for you to find something that is of interest to you that you want to keep working on.

Rishabh Suthar (May 18 2020 at 14:12):

Hi @Sean , I was wondering if there is any scope to use C++ multi-threading along with OpenCL for these primitives?

Sean (May 18 2020 at 18:55):

@Rishabh Suthar no, that's not within scope, but whatever you work on does need to be thread safe. the opencl codebase you're working already runs in parallel with threading. you don't need to do anything in that regard.

Sean (May 18 2020 at 18:57):

Sean (May 20 2020 at 15:17):

@Rishabh Suthar thank you for filling out the wiki and starting a web log -- did you finish all the checklist?

Rishabh Suthar (May 23 2020 at 12:13):

Yes, I've finished the checklist. Sorry for the delay in reply, internet services were hit due to supercyclone Amphan here. Everything is normal now.

Rishabh Suthar (May 23 2020 at 12:14):

Regarding the C++ parallel, I'd read this concept earlier, hence I wanted to explore the possible scope for this.

Sean (May 23 2020 at 15:36):

@Rishabh Suthar If you make progress on opencl in other areas quick enough, there will probably be some things you would work on with C++ parallelism. Where's your project plan at? We can make sure there is some time allocated to explore this at the end if it's something that interests you a lot.

Rishabh Suthar (May 23 2020 at 15:53):

@Sean I'd be happy to explore that. I've kept some buffer time in my proposed project plan. If all goes well, I'll try to wrap up the OpenCL primitives part in 2 months and dedicate the last month to work on C++ parallelism. I'll now start working on arbn primitive in the first week as proposed.

Sean (May 23 2020 at 16:51):

@Rishabh Suthar that sounds good. Where's your development plan at? Would you post the link?

Rishabh Suthar (May 26 2020 at 20:57):

Rishabh Suthar (Jun 03 2020 at 12:39):

Hi @Sean , did you have a look and review the CLINE primitive patch which I submitted earlier? I'll make the necessary changes, if required.

Rishabh Suthar (Jun 05 2020 at 21:56):

Rishabh Suthar (Jun 07 2020 at 06:27):

Hi @Sean , I was testing the opencl kernel with -z flag. But it seems that after compiling nothing happens, the log prints out raytracing aborted and no rendering is happening.
Following is the commands I used:
mged> rt -z 1
and its prints out:
Compiling OpenCL programs...
Raytrace aborted.
Could you please let me know the correct usage of -z flag. I could not find anything much regarding this flag in documentation.

Sean (Jun 08 2020 at 18:42):

Sean (Jun 08 2020 at 18:43):

I'm not sure the -z flag takes an option. Specifying it tells rt to use OpenCL during rendering if it was enabled during compile.

Sean (Jun 08 2020 at 18:44):

Ah, looks like it does take an arg, an int that is just set to 1 like you did to turn on opencl.

Sean (Jun 08 2020 at 18:45):

It sounds like something made it stop during the opencl compilation step. Maybe try with a simpler model or even fewer rt flags if others were specified, or run in GDB debugger to see if you see why it's aborting.

Rishabh Suthar (Jun 09 2020 at 14:47):

Hi @Sean , I am using trunk. I just use -z flag for rendering using opencl and I did build with opencl enabled, I tried this with the simplest model only, on arb8, I was expecting all the primitives which have been previously parallelized should work successfully, but none of them is renders with -z flag. Sure i will try GDB debugger and let you know.

Sean (Jun 09 2020 at 14:48):

Yeah, a simple arb8 should work. A generic failure like that could mean almost anything. Have you confirmed that you have an opencl driver installed and working?

Rishabh Suthar (Jun 09 2020 at 14:50):

Yes opencl works fine on my laptop, I have written some general codes which run fine.

Rishabh Suthar (Jun 09 2020 at 14:54):

Could you please try rendering any simple primitive on your machine? using the same command which I am using, rt -z 1. It might also be that building BRL-CAD did not catch the opencl driver in my machine, which I will check once again.

Sean (Jun 09 2020 at 15:01):

Rishabh Suthar (Jun 09 2020 at 15:02):

Rishabh Suthar (Jun 15 2020 at 17:08):

Hi @Sean , did you test rendering using opencl? My build has opencl enabled, but still it doesn't render.

Rishabh Suthar (Jun 23 2020 at 18:19):

Hi @Sean, I have submitted the pipe patch, it was a long one so took some time sorry for the delay and I have already started working on next item in the list. Please let me know if you have tried rendering on your machine. Is there any documentation specific to opencl, which can help me with rendering in opencl.

Sean (Jun 23 2020 at 18:20):

Erik (Jun 27 2020 at 00:40):

Sean (Jul 01 2020 at 07:20):

@Rishabh Suthar Can you write up a summary of all your progress to date? I'd like to send out an announcement. If you can show a video render of one of the opencl primitives compared with non-opencl, that would be great to include. It can be just 1 page on google docs, a pdf, or a blog post, maybe link to it in your log and here so people can read it.

I'm almost through your patches, so will update you soon on that status. I have some feedback to give.

Rishabh Suthar (Jul 03 2020 at 06:19):

Erik (Jul 03 2020 at 13:19):

starting into dsp, neato :) Are there images to share and/or is this close to where I could drop it on some real hw to see if there's a good speed-up? (I seem to have some interesting nvidia stuff handy... can't ask for a100 time for something like this, but heck, v100, sure...)

Sean (Jul 03 2020 at 13:33):

@Rishabh Suthar I would really like to see a bit more detail than that. I can't help you at all when you write "Worked on..." though that is good context to start with. Just need like 3 sentences. Not just awareness of what you worked on, but what did you get working, what did you not get working. What you're working on is intrinsically graphical, so it would be good to see a picture or statistic at least once a week.

Rishabh Suthar (Jul 05 2020 at 11:15):

Rishabh Suthar (Jul 05 2020 at 11:21):

@Erik yeahh, dsp seems to be most challenging till now. I've developed arbn and pipe primitive. Can you give it a try? I wanna know how they perform in that hw. :D I'll send the MR links.

Rishabh Suthar (Jul 05 2020 at 18:50):

Rishabh Suthar (Jul 13 2020 at 17:46):

@Sean I've kept dsp primitive on hold for now. Would want to get hands-on on other primitives to get the ball rolling. I've submitted VOL primitive patch and am working on metaball now.
Let me know when you review it.

Rishabh Suthar (Jul 13 2020 at 18:00):

@Sean also, I was trying to update the wiki logs but I'm unable to access the website. Is it having some issue?

Sean (Jul 13 2020 at 19:35):

Yes, @Rishabh Suthar apache crashed for some unknown reason, but it's back up. keeping an eye on it. try again?

Sean (Jul 22 2020 at 14:02):

@Rishabh Suthar how's it going? It's time for an in-depth review of where you're at on the project. Please let me know when you're available.

Sean (Jul 22 2020 at 20:07):

First up on the agenda after updating logs, we can discuss the -z option to make sure opencl compilation is working. First and foremost, re-run cmake for me and show me the entire cmake output -- if you're on linux, you can save the output to a log file while seeing it output with something like:

cmake -DBRLCAD_ENABLE_OPENCL=ON path/to/src 2>&1 | tee cmake.log

Rishabh Suthar (Jul 23 2020 at 14:20):

Hey @Sean , good news! I made the -z flag running as expected, finally! I'd to change FindOpenCL.cmake file to ensure it catches the right path of OpenCL in my system. Huhhh. I'll revisit the patches and update them again. Also, will include a documentation around this so that next time someone else doesn't face the same issue. :D

Sean (Jul 23 2020 at 15:18):

that's great to hear @Rishabh Suthar and yes please do update all the patches now that you can test them to make sure they compile and run. if you have a change to the cmake file, that'd be a good patch too.

Sean (Jul 23 2020 at 15:19):

Rishabh Suthar (Jul 23 2020 at 18:03):

@Sean Yeah, will keep the logs in similar format. thanks.
I wanted to know if there is any predefined file or inputs for rendering VOL primitive. It gets 'segmentation fault' most of the time.

Rishabh Suthar (Jul 27 2020 at 18:24):

Hey @Sean , it seems there was a bug in master code itself. None of the previously done primitives were working in OpenCL. It said "Failed to set OpenCL arguments". I tried with ELL and ARB8. However, I've resolved the code with immense effort. It was due to a mismatch between uchar2 and uchar3 in different function declaration. They are now rendering fine. I'll include a patch for this.

Sean (Jul 27 2020 at 18:25):

Rishabh Suthar (Jul 27 2020 at 18:27):

Erik (Jul 29 2020 at 15:54):

Rishabh Suthar (Jul 31 2020 at 05:58):

@Erik Hey, I'm trying to see how can I pass r_min and r_max for metaball primitive or if I can calculate it inside the shot function itself!

Rishabh Suthar (Aug 02 2020 at 11:11):

Hey, I've added the documentation of the issues I faced in the dev logs. Can you have a look and let me know if anything else should be added for better clarification?

Sean (Aug 03 2020 at 06:39):

Rishabh Suthar (Aug 04 2020 at 08:17):

It seems like I missed out on doing "svn add" of cline_shot.cl file in cline primitve patch submitted during the GSoC application period. My bad! It is missing from the patch file. Will redo it and test again.

Sean (Aug 04 2020 at 18:44):

Rishabh Suthar (Aug 05 2020 at 20:42):

Hey @Sean , how can I render CLINE primitive? I can't find any sample fastgen4 file. Is there any documentation around this which can help me?

Sean (Aug 05 2020 at 21:34):

@Rishabh Suthar just run rt to render them. You’ll of course need to create one. I don’t think the “in” command will make one, but you should check. We have some sample fastgen files in the repo (regress or db dir), check them first.

Sean (Aug 05 2020 at 21:34):

starseeker (Aug 05 2020 at 21:41):

Rishabh Suthar (Aug 06 2020 at 07:25):

Rishabh Suthar (Aug 06 2020 at 07:28):

Rishabh Suthar (Aug 10 2020 at 06:02):

Sumagna Das (Aug 10 2020 at 06:40):

there was a conversation between Sean and Thusal about making a vol in the #general stream

Thusal Ranawaka (Aug 10 2020 at 08:13):

Rishabh Suthar (Aug 10 2020 at 17:19):

Rishabh Suthar (Aug 13 2020 at 20:22):

Hey @Sean , I'm still unable to do printf in _shot functions. I tried both printf and bu_log, nothing worked. Any suggestion on what else should I try?

Rishabh Suthar (Aug 13 2020 at 20:23):

It becomes difficult to debug for the primitives which are compiling error-free for not rendering. I can't understand where is it facing the logical error.

Rishabh Suthar (Aug 15 2020 at 13:59):

Hi @Sean , I tried with the Superell patch. I'm attaching the .c and .cl renderings. They do not seem exactly the same, is this expected or do I debug it further? sup_c.png sup_cl.png

Sean (Aug 16 2020 at 18:15):

Neither of those look valid to my eyes.. maybe zoom out more so you can see what's going on? Try very simple superell parameters.

Rishabh Suthar (Aug 17 2020 at 06:26):

I tried "in" command with input parameters but it fails to make one. It throws in some error wrt major/minor axis. So I did this with "make" command in MGED and rendered it. Let me try again.

Rishabh Suthar (Aug 17 2020 at 06:27):

I've also started documenting MGED commands in my wiki logs with simple input parameters for making different primitives. I'll keep on adding as and when I find a command for respective primitive. It might help others who face similar issue in future.

Sean (Aug 18 2020 at 06:15):

did you try a simple opencl demo to see if you can get it to print inside a compute kernel? I would have expected bu_log to give you a compilation error, so that's a very odd if it didn't.

Sean (Aug 18 2020 at 06:16):

This implies that the values you used are probably not valid, not in range. Can search the web to find a set of real parameters that should work.

Sean (Aug 18 2020 at 06:17):

Sean (Aug 18 2020 at 06:18):

ah, that's only interactive in maple, but there are some actual values there you can try

Rishabh Suthar (Aug 18 2020 at 09:51):

Rishabh Suthar (Aug 18 2020 at 10:08):

Yeah, I tried that. With printf, it was not able to create context itself. The bu_log did give errors. I imported all the necessary functions in common.cl but didn't work.

Rishabh Suthar (Aug 18 2020 at 19:36):

Rishabh Suthar (Aug 18 2020 at 19:37):

Rishabh Suthar (Aug 18 2020 at 19:38):

I did this via "make" command. I'm not yet able to use "in" command. I used ell parameters and added 0/1/2 values for n,e parameter in superell but it still gave "rt_db_external5_to_internal5(superell.s): unable to import non-BRL-CAD object, major=255 minor=35" error log.

Rishabh Suthar (Aug 18 2020 at 19:41):

Rishabh Suthar (Aug 19 2020 at 19:10):

Hey @Sean , I cloned the repository again and started from scratch, superell C rendering worked with parameter values. I don't know why it was not working in my previous repository. Blah.

Rishabh Suthar (Aug 19 2020 at 19:11):

Anyway, I tried with HYP primitive and was able to successfully render both C and CL versions.

Rishabh Suthar (Aug 19 2020 at 19:11):

Rishabh Suthar (Aug 19 2020 at 19:12):

I think with the other primitives, I'm facing issue with memory allocation which is not working well. Probably that's why they are not rendering an image in CL versions.

Rishabh Suthar (Aug 19 2020 at 19:14):

Also, did the security certificate of brlcag.org expire? It is giving me safety warnings while trying to visit.

Erik (Aug 19 2020 at 23:43):

@Rishabh Suthar : can you re-render with the light at the same place and pixdiff?

Erik (Aug 19 2020 at 23:44):

Sean (Aug 19 2020 at 23:45):

@Erik dag nab it.. again??! There's a cron job that runs their updater daily, but it's been not working reliably (usually something in python updates and it stops running).

Sean (Aug 19 2020 at 23:47):

@Rishabh Suthar what's the difference between the two hyp rendering's performance? Can you show me the summary from both their logs (the RTFM lines in particular)?

Sean (Aug 19 2020 at 23:47):

if you're not already, you'll probably want to keep two directories -- one with opencl enabled and one without so you can keep two compiles for comparison.

Rishabh Suthar (Aug 20 2020 at 17:46):

Rishabh Suthar (Aug 20 2020 at 17:47):

Rishabh Suthar (Aug 20 2020 at 19:25):

@Erik How can I use pixdiff ? I saw this https://brlcad.org/~nouhrasofat/man1/en/pixdiff.php but it is not working. I wrote a short python code for pix diff. Both have same size and channels but there are few non zero in b,g,r arrays! Is this fine or are we just trying to verify the intersection points?

Rishabh Suthar (Aug 20 2020 at 19:25):

It says pixdiff is not a command. It needs npm install and couldn't find any other command similar to this!

Rishabh Suthar (Aug 20 2020 at 19:41):

Rishabh Suthar (Aug 20 2020 at 19:42):

Sean (Aug 21 2020 at 16:12):

there's not a save log option, so you can either run copy-paste or run rt outside mged and redirect output to a file using usual means

Rishabh Suthar (Aug 22 2020 at 18:16):

Got it. Anyway, did you get a chance to look at the logs I shared? The CPU performance has increased. I used -s2048 flag for heavy rendering.

Rishabh Suthar (Aug 24 2020 at 15:27):

@Sean , this being the last week of GSoC, I wanted to document this well for future reference. Are there any protocols as to how should I document this or any other last week tasks of GSoC?

Sean (Aug 24 2020 at 19:38):

So if you didn't catch it in that summary there @Rishabh Suthar -- the performance logs you shared show it being 0.3 seconds in non-ocl and 0.02 seconds in ocl mode. That's more than a 10x improvement

Sean (Aug 24 2020 at 19:39):

pixdiff is installed in BRL-CAD.... it's in the same dir as mged and rt and company

Sean (Aug 24 2020 at 19:42):

Yes, you should pull together a final report that shows before and after for all the entities that you got converted, ideally with a picture and performance number for each. Make sure all your patches work with the latest trunk sources too, just in case something changed recently, and I'll work with you to get it all integrated asap.

Rishabh Suthar (Aug 24 2020 at 19:47):

Rishabh Suthar (Aug 24 2020 at 19:48):

Sean (Aug 24 2020 at 19:49):

Whatever is most comfortable for you is fine for writing it, but the final one should end up on our site so it remains available -- in case you accidentally move/delete the doc from your Google Drive, for example

Sean (Aug 24 2020 at 19:50):

you said you used opencv, not pixdiff right? I don't know what they do or what routines you used or what their output means without reading up on it more.

Sean (Aug 24 2020 at 19:50):

Rishabh Suthar (Aug 24 2020 at 19:51):

I basically calculated the pixel difference between the two images using opencv. Let me try pixdiff you mentioned.

Rishabh Suthar (Aug 24 2020 at 19:55):

Rishabh Suthar (Aug 24 2020 at 19:56):

pixdiff bytes: 5887661 matching, 887771 off by 1, 5807480 off by many
This was the terminal output

Sean (Aug 24 2020 at 20:54):

Sean (Aug 24 2020 at 20:56):

starseeker (Aug 24 2020 at 21:07):

Sean (Aug 25 2020 at 01:39):

Looks like it, maybe. RGB values on the top face (ocl) go from 117/117/117 to 124/124/124 and on the bottom face (rt) from 110/110/110 to 115/115/115.

Sean (Aug 25 2020 at 01:40):

@Rishabh Suthar so the pixdiff image shows where the color values differ by more than 1 value in one or more of the RGB channels. Most of the pixels are offset in intensity by just a little bit, which implies some calculation is just slightly off.

Sean (Aug 25 2020 at 01:41):

The most important part is that hits vs miss appears to be correct. It would be informative to compare the same nirt shotline in both to make sure the hits are at least identical. If they are, it would confirm this is a normal issue.

Sean (Aug 25 2020 at 06:19):

@Rishabh Suthar for what it's worth, your project is a highlight on our facebook feed tody

Rishabh Suthar (Aug 25 2020 at 08:06):

Rishabh Suthar (Aug 28 2020 at 18:49):

Rishabh Suthar (Aug 28 2020 at 18:50):

I tried out the nirt command. Just to confirm, I used 'nirt' command in the MGED terminal after rendering both C and OpenCL versions. The output was same in both.

Rishabh Suthar (Aug 28 2020 at 18:51):

I'll be modifying the ToDo part a bit more with technical details for better clarification.

Sean (Aug 28 2020 at 19:27):

Can you show the output of nirt? There's different output forms that will print more precision than the default. Might be needed to detect if they're actually identical. Post the .g's and I can help take a look at them.

Rishabh Suthar (Aug 28 2020 at 19:35):

Origin (x y z) = (0.00000000 0.00000000 0.00000000) (h v d) = (0.0000 0.0000 0.0000)
Direction (x y z) = (-1.00000000 0.00000000 0.00000000) (az el) = (0.00000000 0.00000000)
Region Name Entry (x y z) LOS Obliq_in Attrib
hyp.s ( 100.0000 0.0000 0.0000) 200.0000 0.0000

Rishabh Suthar (Aug 28 2020 at 19:40):

Rishabh Suthar (Aug 28 2020 at 19:41):

Sean (Aug 30 2020 at 05:22):

sort of... is that the c or cl output? is the other character-for-character identical output?

Rishabh Suthar (Aug 30 2020 at 11:46):

Sean (Aug 31 2020 at 01:28):

@Rishabh Suthar so you shot directly down the X axis. instead can you shoot through one of the upper sides where we know the hits or normals deviate? If anything, we should be able to see the normal change -- I think you'll have to pick a different nirt output format in order for it to print the normal (see the NIRT guide on brlcad.org/wiki/Documentation for details and/or nirt -? .. it's the -fmt option)

Sean (Aug 31 2020 at 01:28):

If you run saveview in one, you can then run loadview in the other mged to make sure you're shooting the same ray.

Rishabh Suthar (Sep 01 2020 at 08:14):

Rishabh Suthar (Sep 01 2020 at 17:27):

Origin (x y z) = (0.00000000 0.00000000 0.00000000) (h v d) = (0.0000 0.0000 0.0000)
Direction (x y z) = (0.42426407 0.56568542 0.70710678) (az el) = (-126.86989765 -45.00000000)
Region Name Entry (x y z) LOS Obliq_in Attrib
hyp.s (-107.7632 -143.6842 -179.6053) 508.0005 70.7960

Rishabh Suthar (Sep 01 2020 at 17:28):

Rishabh Suthar (Sep 01 2020 at 17:29):

I however am not sure the difference b/w c and cl one. Nirt will shoot irrespective of rt is done via c or opencl. How can we ensure it shoots through the cl primitive made?

Rishabh Suthar (Sep 01 2020 at 17:30):

I mean, doing nirt after make command also gives the output, which means it is shooting through the primitive formed. Will it shoot through the rendered primitive as well?

Sean (Sep 01 2020 at 18:41):

Sean (Sep 01 2020 at 18:42):

does nirt have a -z option? if not, maybe add one to it as well that makes it enable opencl like rt does

Sean (Sep 01 2020 at 18:43):

it's not a c or cl primitive -- the geometry is one and the same no matter what. we're just evaluating that geometry with either c ray tracing or cl ray tracing.

Sean (Sep 01 2020 at 18:43):

my asking you for two .g's was probably misleading in hindsight. I just wanted to make sure you weren't using different geometry for each.

Sean (Sep 01 2020 at 18:45):

there should be no problem using just one .g file. the questions we need to confirm is 1) whether the hit point of some random non-axis-aligned ray is identical with -z and without -z and 2) whether the calculated normal is identical with and without -z

Rishabh Suthar (Sep 02 2020 at 13:59):

It doesn't have a -z flag. Yeah, we could add one. Will include this task in final report as well.

Rishabh Suthar (Sep 02 2020 at 14:01):

without nirt, for now maybe we can compare the view in different angles in c and cl cases. I'll look online if there is any other tool to check this.

Sean (Sep 02 2020 at 15:37):

@Rishabh Suthar rt might be able to give us what we need since it already has the -z option. i'm not sure any other tool is going to help as we need it to go through the opencl pipeline which is only accessible through rt currently.

Sean (Sep 02 2020 at 15:37):

Sean (Sep 02 2020 at 15:58):

okay, I figured it out ... I don't use this very often but it should be exactly what we need

Sean (Sep 02 2020 at 15:58):

Sean (Sep 02 2020 at 16:00):

that should give a non-cl output, then of course run again with with -z1 to get cl output: rt -b "256 256" -F/dev/debug -X10 -z1

Sean (Sep 02 2020 at 16:00):

Sean (Sep 02 2020 at 16:01):

actually, lets add the -x4 debug flag too: rt -b "256 256" -F/dev/debug -X10 -x4

Sean (Sep 02 2020 at 16:01):

Sean (Sep 02 2020 at 16:03):

and just copy paste the whole output of each between two ``` blocks, so it looks like:

Sean (Sep 02 2020 at 16:03):

mged> rt -b "256 256" -F/dev/debug -X10 -x4
BRL-CAD Release 7.31.0  The BRL-CAD Raytracer RT
    Sun, 30 Aug 2020 14:34:09 -0400, Compilation 10
    morrison@agua.local
BRL-CAD Release 7.31.0  The BRL-CAD Ray-Tracing Library
    Sun, 30 Aug 2020 14:34:09 -0400, Compilation 10
    morrison@agua.local
BRL-CAD Release 7.31.0  The BRL-CAD Numerical Computation Library
    Sun, 30 Aug 2020 14:34:09 -0400, Compilation 10
    morrison@agua.local
BRL-CAD Release 7.31.0  The BRL-CAD Utility Library
    Sun, 30 Aug 2020 14:34:09 -0400, Compilation 10
    morrison@agua.local

Compile-time debug symbols are available
Running on agua.local
libbu bu_debug=x1 <COREDUMP>
librt rt_debug=x4 <SHOOT>
rt optical_debug=x10 <SHADE>
/Users/morrison/brlcad.trunk/.build/bin/rt -M -b 256 256 -F/dev/debug -X10 -x4 -u model
opendb /Users/morrison/brlcad.trunk/.build/test.g;
tree ;
db title:  Untitled BRL-CAD Database
DIRBUILD: cpu = 0.000275 sec, elapsed = 0.000456 sec
    parent: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
  children: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
Additional #malloc=244, #free=214, #realloc=14 (30 retained)
0x109c68030 TOL 5.000000e-04 (sq=2.500000e-07) perp=1.000000e-06, para=9.999990e-01
BRL-CAD Release 7.31.0  The BRL-CAD Optical Shader Library
    Sun, 30 Aug 2020 14:34:09 -0400, Compilation 10
    morrison@agua.local
Additional #malloc=2053, #free=5, #realloc=1 (2048 retained)
GETTREE: cpu = 0.000326 sec, elapsed = 0.000437 sec
    parent: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
  children: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
fb_open(0x7f98edc110d0, "/dev/debug", 512, 512)
fb_view(0x7f98edc110d0,  256,  256,    1,    1)

...................Frame     0...................
PREP: cpu = 0.000128 sec, elapsed = 0.000142 sec
    parent: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
  children: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
Additional #malloc=1409, #free=1373, #realloc=10 (36 retained)
NUBSP: 0 cut, 1 box (1 empty)
Tree: 1 solids in 1 regions
Model: X(-500, 500), Y(-500, 500), Z(-500, 500)
View: 35 azimuth, 25 elevation off of front view
Orientation: 0.248097, 0.476591, 0.748097, 0.389435
Eye_pos: 2571.76, 1800.77, 1463.99
Size: 2000mm
Grid: (3.90625, 3.90625) mm, (512, 512) pixels
Beam: radius=1.95312 mm, divergence=0 mm/1mm
only pixel 256 256
Mode: scanline-per-CPU buffering
Lighting: Ambient = 40%
  Implicit light 0: (3887.74, 1501.45, 1886.61), aimed at (0, 0, -1)
  Implicit light 0: invisible, no shadows, 1 lumens (83%), halfang=180


  **********shootray cpu=0  256, 256 lvl=0 a_onehit=-1 (main ray)
  Pnt (2571.7624676893201467, 1800.767466360870003, 1463.9926030826702572)
  Dir (-0.74240387650610395465, -0.51983679072568422797, -0.42261826174070005191)
  BOX #1 interval is 2790.61..4137.59
  0x109c681d8 BOX Contains 1 primitives (2 alloc), 0 primitives with pieces:
           min (-500.000000, -500.000000, -500.000000)
         max (500.000000, 500.000000, 500.000000)
            sph
  shooting sph
  Waiting segs:
    0x7f98ee016c00: SEG sph (2964.1, 3964.1) st_bit=0 xray#=0
  ------a_hit()
    0x7f98edd17750: PT sph (SPH#0) sph (SPH#0) (2964.1, 3964.1)
      InHIT dist=2964.1 (surf 0)
     OutHIT dist=3964.1 (surf 0)
      Primitives: sph,
      Untrimmed Segments spanning this interval:
        0x7f98ee016c00: SEG sph (2964.1, 3964.1) st_bit=0 xray#=0
      Region: /s.r
  ------
colorview calling viewshade
  viewshade(/s.r)
   Using "plastic" shader, mfp_inputs=x1 <NORMAL>
  Surface normal for shader:
  hit pt: 371.202 259.918 211.309 end pt: 384.061 268.922 218.629
  Shadeworkbefore mf_render: 0x7ffeeb507538
   sw_inputs=x9 <HIT,NORMAL> sw_hit.dist:2964.1 @ sw_hit.point(371.202 259.918 211.309)
   sw_hit.normal(0.742404 0.519837 0.422618)
   sw_transmit 0.000000
   sw_reflect 0.000000
   sw_refract_index 1.000000
   sw_extinction 0.000000
   sw_color (1.000000, 0.000000, 0.000000)
 sw_basecolor (1.000000, 0.000000, 0.000000)
 sw_uv  0.000000 0.000000
   sw_dudv  0.000000 0.000000
   sw_xmitonly 0

  phong_render
    shine=10
    specular=0.699999999999999955591079
    diffuse=0.2999999999999999888977698
    transmit=0
    reflect=0
    ri=1
    extinction_per_meter=0
    emission=0,0,0
  Shadeworkafter mf_render: 0x7ffeeb507538
   sw_inputs=x9 <HIT,NORMAL> sw_hit.dist:2964.1 @ sw_hit.point(371.202 259.918 211.309)
   sw_hit.normal(0.742404 0.519837 0.422618)
   sw_transmit 0.000000
   sw_reflect 0.000000
   sw_refract_index 1.000000
   sw_extinction 0.000000
   sw_color (1.086587, 0.444181, 0.444181)
 sw_basecolor (1.000000, 0.000000, 0.000000)
 sw_uv  0.000000 0.000000
   sw_dudv  0.000000 0.000000
   sw_xmitonly 0


  ----------shootray cpu=0  256, 256 lvl=0 (main ray) HIT ret=1
SHOT: cpu = 0.000236 sec, elapsed = 0.000306 sec
    parent: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
  children: 0.0user 0.0sys 0:00real 0% i+d maxrss +pf csw
Additional #malloc=310, #free=300, #realloc=31 (10 retained)
1 solid/ray intersections: 1 hits + 0 miss
pruned 100.0%:  0 model RPP, 0 dups skipped, 0 solid RPP
Frame  0:     262144 pixels in      0.00 sec = 1110779661.02 pixels/sec
Frame  0:          1 rays   in      0.00 sec =      4237.29 rays/sec (RTFM)
Frame  0:          1 rays   in      0.00 sec =      4237.29 rays/CPU_sec
Frame  0:          1 rays   in      0.00 sec =      3267.97 rays/sec (wallclock)

if_flush(0x7f98edc110d0)
fb_close(0x7f98edc110d0)

Sean (Sep 02 2020 at 16:06):

the most important lines we'll be paying attention to are the Pnt,Dir lines, the InHit,OutHit lines, the hit,end pt shading lines, and the sw_* lines.

Rishabh Suthar (Sep 03 2020 at 18:24):

Sean (Sep 03 2020 at 18:25):

Rishabh Suthar (Sep 03 2020 at 18:26):

Sean (Sep 03 2020 at 18:27):

well... then I guess we probably have our answer for why the images are different

Sean (Sep 03 2020 at 18:27):

it's apparently not going through liboptical for the lighting, must be doing its own thing

Rishabh Suthar (Sep 03 2020 at 18:30):

Sean (Sep 03 2020 at 18:34):

Rishabh Suthar (Sep 03 2020 at 18:34):

Sean (Sep 03 2020 at 18:34):

the code ends up calling clt_frame() which is up in src/librt/primitives/primitive_util.c .. and in there it's doing shading in opencl too

Sean (Sep 03 2020 at 18:37):

src/librt/primitives/rt.cl has a shade_segs() function that is doing something similar, but obviously not identical to what liboptical is doing

Rishabh Suthar (Sep 03 2020 at 18:57):

Sean (Sep 03 2020 at 21:52):

Sean (Sep 03 2020 at 21:53):

since that way we can get the in/out hit point and normal without involving optics

Sean (Sep 07 2020 at 08:12):

@Rishabh Suthar what are your thoughts on turning your GSoC report into a formal write-up report? If that's something you'd be interested in, I'd be happy to sponsor and help you with getting it submitted to some technical journal interested in OpenCL/GPGPU conversion.

Sean (Sep 07 2020 at 08:12):

Regardless, where do we stand on the other patches -- which ones compile cleanly with OpenCL enabled?

Rishabh Suthar (Sep 07 2020 at 08:35):

That'd be indeed be interesting. I've never done this before. Please give me some time while I get back to you on this after clearing out all my upcoming commitments.

Rishabh Suthar (Sep 07 2020 at 08:37):

There is one with the bug resolution (551), one with updated FindOpenCL.cmake (549) and the HYP primitive (553) which can be merged in master.

Stream: Google Summer of Code

Topic: OpenCL Raytracing

Rishabh Suthar (Mar 29 2020 at 15:49):

Rishabh Suthar (Mar 30 2020 at 16:20):

Daniel Rossberg (Mar 30 2020 at 16:49):

Rishabh Suthar (Mar 30 2020 at 20:30):

Sean (Mar 31 2020 at 05:50):

Sean (Mar 31 2020 at 05:52):

Sean (Mar 31 2020 at 06:26):

Rishabh Suthar (Mar 31 2020 at 16:16):

Sean (Apr 21 2020 at 17:40):

Rishabh Suthar (Apr 22 2020 at 15:35):

Rishabh Suthar (May 05 2020 at 05:21):

Sean (May 05 2020 at 05:58):

Rishabh Suthar (May 18 2020 at 14:12):

Sean (May 18 2020 at 18:55):

Sean (May 18 2020 at 18:57):

Sean (May 20 2020 at 15:17):

Rishabh Suthar (May 23 2020 at 12:13):

Rishabh Suthar (May 23 2020 at 12:14):

Sean (May 23 2020 at 15:36):

Rishabh Suthar (May 23 2020 at 15:53):

Sean (May 23 2020 at 16:51):

Rishabh Suthar (May 26 2020 at 20:57):

Rishabh Suthar (Jun 03 2020 at 12:39):

Rishabh Suthar (Jun 05 2020 at 21:56):

Rishabh Suthar (Jun 07 2020 at 06:27):

Sean (Jun 08 2020 at 18:42):

Sean (Jun 08 2020 at 18:43):

Sean (Jun 08 2020 at 18:44):

Sean (Jun 08 2020 at 18:45):

Rishabh Suthar (Jun 09 2020 at 14:47):

Sean (Jun 09 2020 at 14:48):

Rishabh Suthar (Jun 09 2020 at 14:50):

Rishabh Suthar (Jun 09 2020 at 14:54):

Sean (Jun 09 2020 at 15:01):

Rishabh Suthar (Jun 09 2020 at 15:02):

Rishabh Suthar (Jun 15 2020 at 17:08):

Rishabh Suthar (Jun 23 2020 at 18:19):

Sean (Jun 23 2020 at 18:20):

Erik (Jun 27 2020 at 00:40):

Sean (Jul 01 2020 at 07:20):

Rishabh Suthar (Jul 03 2020 at 06:19):

Erik (Jul 03 2020 at 13:19):

Sean (Jul 03 2020 at 13:33):

Rishabh Suthar (Jul 05 2020 at 11:15):

Rishabh Suthar (Jul 05 2020 at 11:21):

Rishabh Suthar (Jul 05 2020 at 18:50):

Rishabh Suthar (Jul 13 2020 at 17:46):

Rishabh Suthar (Jul 13 2020 at 18:00):

Sean (Jul 13 2020 at 19:35):

Sean (Jul 22 2020 at 14:02):

Sean (Jul 22 2020 at 20:07):

Rishabh Suthar (Jul 23 2020 at 14:20):

Sean (Jul 23 2020 at 15:18):

Sean (Jul 23 2020 at 15:19):

Rishabh Suthar (Jul 23 2020 at 18:03):

Rishabh Suthar (Jul 27 2020 at 18:24):

Sean (Jul 27 2020 at 18:25):

Rishabh Suthar (Jul 27 2020 at 18:27):

Erik (Jul 29 2020 at 15:54):

Rishabh Suthar (Jul 31 2020 at 05:58):

Rishabh Suthar (Aug 02 2020 at 11:11):

Sean (Aug 03 2020 at 06:39):

Rishabh Suthar (Aug 04 2020 at 08:17):

Sean (Aug 04 2020 at 18:44):

Rishabh Suthar (Aug 05 2020 at 20:42):

Sean (Aug 05 2020 at 21:34):

Sean (Aug 05 2020 at 21:34):

starseeker (Aug 05 2020 at 21:41):

Rishabh Suthar (Aug 06 2020 at 07:25):

Rishabh Suthar (Aug 06 2020 at 07:28):

Rishabh Suthar (Aug 10 2020 at 06:02):

Sumagna Das (Aug 10 2020 at 06:40):

Thusal Ranawaka (Aug 10 2020 at 08:13):

Rishabh Suthar (Aug 10 2020 at 17:19):

Rishabh Suthar (Aug 13 2020 at 20:22):

Rishabh Suthar (Aug 13 2020 at 20:23):

Rishabh Suthar (Aug 15 2020 at 13:59):

Sean (Aug 16 2020 at 18:15):