[GEM-dev] frambuffer and Vertex Texture Fetching

[cyrille henry]

well, the error is self explanatory.
your hardware limit is 0 vertex shader sample maximum, and you try to load 1.

so, this is a hardware limitation.

in order to use this patch, you need a glsl 3.0 hardware i think. i realize that this is not very used yet.

thanks for testing this

cyrille


Jack a écrit :
> 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
> 
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
> 
>