PcloudStimulusBuffer::produceFrameReq():
Now correctly produces into the stim frames for the
PcloudIntensityStimulusBuffer object that's attached to the
PcloudStimulusProducer. If there's no attached I stimbuff, then
the OpenCL kernel will simply not write out the intensity data.
This is the first moment when we actually use the SP-MC ringbuffer
properly and actually cycle through the frames, producing into
them one by one.
This now ensures that finalizeReq is indeed called from mrntt,
since exception-experiencing threads will post an exceptionInd
to mrntt, which will then call finalizeReq.
This ensures that we can avoid races when adding and removing
stimbuffs to a stimproducer.
At least in theory. I can think of some ways in which this current
design may result in races or other bad conditions.
Slots whose stride size is larger than the slot alignment value
should have their size rounded up to the alignment size so that
the slots that follow them will also be aligned.
We added a new centralized OpenCL Compute manager. This can later
be extended to support CUDA, SyCL, etc. SMO can be configured at
build time to choose which API it will use for compute.
Moreover, the ComputeMgr allows us to register buffers which are
available to all cl_contexts.
We now allocate all the stimFrames for a StimBuffer using a
single StagingBuffer. This gives us all the benefits we're
looking for (pinning, alignment, etc).
We can simplify and universalize the logic here by acknowledging that
assemblyCycleComplete() will always destroy the current eventfdDesc
object, so we can just check that to see whether we should continue
the assembly cycle.
* PcloudStimulusProducer now has member sh_ptr<StimulusBuffer>s.
* StimulusProducer now has a vector<sh_ptr<StimulusBuffer>s.
Created new stimbuff-type-specific
Pcloud[Xyz|I|Ambience]StimulusBuffer classes for representing each
stim feature exposed by livoxGen1's PcloudStimulusProducer.
Doing it this way enables us to get the mapBuffer() call working
during finalize. But we couldn't get the unmap call working. That
has to do with a bug in the Rusticl event waiting code.