[PD] GEM on PIII memory problem?

[rolf meesters]

On Mon, Jan 16, 2012 at 1:29 PM, Cyrille Henry <ch at chnry.net> wrote:

>
>
> Le 16/01/2012 13:23, rolf meesters a écrit :
>
>
>>
>> On Sun, Jan 15, 2012 at 10:47 PM, Cyrille Henry <ch at chnry.net <mailto:
>> ch at chnry.net>> wrote:
>>
>>
>>
>>    Le 15/01/2012 18:13, rolf meesters a écrit :
>>
>>        it's at the max of 64 Mb.
>>
>>    do you have 16 pix_image?
>>    if you load 16 time the same image, you need 16 time more memory than
>> necessary.
>>
>>    then, you could use a single gemhead / pix_image / pix_texture to load
>> the image and share the texture Id.
>>    then using gemhead/pix_texture(to load the texture Id)/pix_coordinate
>> on your abstraction.
>>
>>
>>    also, you can only resize the image in order to fit in the available
>> GPU memory.
>>
>>    anyway, pd/GEM should not exit without warning. pd bug report should
>> be made.
>>
>>
>>    Cyrille
>>
>>
>> i have 16 pieces, which are parts of 1 big picture; like with a puzzle
>> they have to be displayed at their specific coordinates.
>> there's no pix_image involved.
>> (the abstraction is attached)
>>
> ah, ok.
> you're using a pix_buffer. good, the image is not loaded many time.
>
> so the only solution i can imagine is to resize the image in order to use
> less memory.
>
> c
>
> a bit of progress:
for the intel815 (which i have on the PIII) it is possible to set a value
for VideoRam
in xorg.conf.
i made it 16384 kb: now Pd/GEM does not quit.
the patch goes through the motions, there's a GEM-window,
but only a white rectangle where a picture should be.

GEM tells me that direct rendering is enabled,
but still only 8 clor bits.

and now every time at a change in the rendering:
GL: invalid operation

r



>
>> rolf
>> btw thanks for reacting
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120116/fba225a7/attachment.htm>