[GEM-dev] pix_share broken several ways

chris clepper cgc at humboldtblvd.com
Thu Jun 8 17:34:45 CEST 2006


On 6/8/06, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
>
> >
> > First, the csize selection does not work.  On OSX it is fixed to 2 and
> > neither 4, r, R, or RGBA changes it.
>
> this is very weird.
> the only reason i can imagine for this is that
> imageStruct.setCsizeByFormat (GL_RGBA) returns something very wrong (like
> enforcing it to be ycbcr and ignoring the argument)...but i doubt it


I put a simple if statement in pix_share_write to replace the imageStruct
call and it works fine.  I think setCSizeByFormat() might not be working on
the Mac.  All those #ifdefs are hard to read!  I will try to replace it with
a single one for __APPLE__ and see if that helps.


>
> > Second, after the shm buffer is set there is no way to change the
> > size.  I get endless amounts of this:
> >
> > pix_share_*: 2048x768x2: 3145728
> > pix_share_*: someone was faster: only got 1572864 bytes instead of
> 3145728
> > pix_share_*: shm:: id(131072) segsz(1572884) cpid (23205)
> mem(0x101F6000)
>
> you mean, you get this error message each render-cycle?
> or do you repeatedly trigger a "set" message to [pix_share_write]?
>
> >
> > Someone was faster?  WTF?  I get that even after deleting the
> > pix_share_write object and recreating it.  Creating the object should
> > set up whatever I tell it to set up.
>
> the difference (iirc) between your original version and the current one
> is, that both [pix_share_read] and [pix_share_write] set up the shared
> memory segment, whichever is faster (read: created earlier)
> so "someone was faster" means, that another object (e.g.
> [pix_share_read]) has already set up an shm-segment with the same id.
> if the shm-segment is already there, then none of the objects try to
> resize it but instead use what is already there.
>
> in order to free the shm-segment you will have to destroy ALL references
> to it (read: all [pix_share_read] and [pix_share_write] objects
> referencing the same segment)


This is the tricky part of these objects to deal with.  You can either allow
the user to whatever they want when setting up shm or put in a check to help
keep them from doing something which might crash or become unusable.  My
original thinking was that anyone using these objects would have to really
know what they are doing to set them up properly and to just let them do
it.

The alternative idea to put checks in place to keep from crashing/etc should
probably be even more complete.  Rather than locking the shm per ID,
pix_share_write should allow for resizing and the pix_share_read objects
would have to be alerted to this change.   In my initial testing (on OSX
only) changing the size of the shm region for a single ID worked.  If this
is not the case on Linux then some other solution will have to be figured
out.

>
> > Finally, after setting up one shm buffer at an address I can no longer
> > create one at any other address.  I get this message:
> >
> > pix_share_*: 2048x768x2: 3145728
> > error: pix_share_*: couldn't get shm_id: error 12
> >
> > Again, I'm telling pix_share_write to create a shm buffer at a certain
> > address and of a certain size.  Why would it refuse to do this?
>
> i'll have a look at that (i cannot remember having that problem)
>
> what comes to my mind is that the symbolic/numeric id exposed given is
> evaluated incorrectly.
> could you please give the exact arguments of the [pix_share*] objects
> you try to create?


This has to do with running out of shm memory.  I was recreating the object
with a new ID and values and it refused to go beyond a certain size.  This
leads me to think that created regions are not being freed since the 4MB
allowance on OSX is used up by the first 1024x768 object.

>
> > The code I checked in did not do this.  I cannot figure out what the
> > intended function of some of the code is and do not know how to make
> > changes other than reverting back to what I know works and continuing
> > from that point.
>
> it would be great if we could make the current version running on your
> system instead of reverting it to a version that is known to crash on
> other systems. (in the end i hope it will work on all systems)


I agree.  I originally wrote the object from some code Chris Klippel used on
Linux back in the old days of jMax video and it worked fine on OSX back then
too.  I could have made a mistake or the Linux spec could have changed since
though.

I made some hacks since I need the code to work right then, so now it's time
for real fixes.  The first thing to figure out is how we want the object to
behave in end use.  Do we allow for any settings or do we confine the
objects even further than they are now?

cgc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060608/febf7c74/attachment.htm>


More information about the GEM-dev mailing list