[GEM-dev] frambuffer and Vertex Texture Fetching

Jack jack at rybn.org
Sun Apr 6 14:15:12 CEST 2008


Hello Cyrille,
Here a problem on PowerBook G4, MacOSX.4.11, GeForce FX Go5200 :

glsl_program]: Info_log:
[glsl_program]: ERROR: Implementation limit of 0 active vertex shader  
samplers (e.g., maximum number of supported image units) exceeded,  
vertex shader uses 1 samplers

[glsl_program]: ARB Link failed!
[glsl_program]: vertex shader running in hardware
[glsl_program]: fragment shader running in hardware

I will try on MacBookPro later.
++

Jack


Le 6 avr. 08 à 01:35, cyrille henry a écrit :

> hello,
>
> http://techreport.com/discussions.x/8872
>
> look like it's not possible with your hardware to get this patch  
> working at full speed.
>
> could anyone else test this patch please?
>
> cyrille
>
> marius schebella a écrit :
>> cyrille,
>> I am using a variation of your patch to get my vertex morphing  
>> working.
>> is just need to figure out a way to save 3d objects as rgb images...
>> marius.
>>
>> cyrille henry wrote:
>>> hello,
>>>
>>> the good new is that things still can work as it was.
>>> just replace rgb32 with rgb.
>>> the old version does not use the same primitive, so i's possible  
>>> there
>>> is more vertex now. this can explain the 70->130% diference.
>>>
>>> we can investigate, i am not sure your card is able to use this
>>> acceleration.
>>>
>>> with a nvidia 7700, this patch use only few %, so the change is  
>>> really
>>> important!
>>>
>>> cyrille
>>>
>>> marius schebella a écrit :
>>>> hi,
>>>> when I click on type byte, format rgb32 then I get this printout
>>>> [gemframebuffer]: type is BYTE, 5121
>>>> [gemframebuffer]: format is GL_RGB_FLOAT32_ATI, 32992
>>>> but it starts eating up all my cpu.
>>>> with the old version I cud run dim 512 512 at ~70%
>>>> with the new version I am +130%
>>>> this is on os x 10.5.2 with ati X1600.
>>>> marius.
>>>>
>>>> cyrille henry wrote:
>>>>> hello,
>>>>> i'm currently investigating the use of framebuffer to create a
>>>>> texture in order to use it as a vertex displacement.
>>>>> this has already been discuss in this list, but new stuff in
>>>>> framebuffer makes me try again.
>>>>>
>>>>> i'm specially motived because it's the last things that prevent me
>>>>> trying physical modeling in glsl.
>>>>>
>>>>>
>>>>>
>>>>> having a look at framebuffer, i noticed strange things :
>>>>> -changing type or format does not init the framebuffer, you  
>>>>> have to
>>>>> change dim, or rectangle (mode) in order to init it.
>>>>> (i don't know why)
>>>>>
>>>>> -in void gemframebuffer :: typeMess(char* type), should :
>>>>>
>>>>>     else if (!strcmp(type, "FLOAT")){
>>>>>       post("type is GL_FLOAT, %d",m_type);
>>>>>       m_type = GL_FLOAT;
>>>>>       return;
>>>>>
>>>>> be replaced by :     else if (!strcmp(type, "FLOAT")){
>>>>>       m_type = GL_FLOAT;
>>>>>       post("type is GL_FLOAT, %d",m_type);
>>>>>       return;
>>>>> ???
>>>>> (it's also the same in formatMess)
>>>>>
>>>>> anyway. here are the good news :
>>>>> i add (and commit) a RGB32 format corresponding to
>>>>> m_internalformat = GL_RGB_FLOAT32_ATI;
>>>>> #ifdef __APPLE__
>>>>>        m_format = GL_BGR;
>>>>> #else        m_format = GL_RGB;
>>>>> #endif
>>>>> (i  don't know if apple definition is ok).
>>>>>
>>>>> but the internal format GL_RGB_FLOAT32_ATI was mandatory in  
>>>>> order to
>>>>> have an efficient implementation of vertex texture fetching.
>>>>>
>>>>> so here is an example. it still need to be cleaned, but i'd  
>>>>> like to
>>>>> know if it work on other computer.
>>>>> (here, it's about 50 time faster than previous example i send to
>>>>> this list)
>>>>>
>>>>> please update/compile and test!
>>>>>
>>>>> cyrille
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------ 
>>>>> ------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> GEM-dev mailing list
>>>>> GEM-dev at iem.at
>>>>> http://lists.puredata.info/listinfo/gem-dev
>>>>
>>>>
>>>>
>>>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev





More information about the GEM-dev mailing list