[GEM-dev] frambuffer and Vertex Texture Fetching
cyrille henry
cyrille.henry at la-kitchen.fr
Sun Apr 6 14:26:04 CEST 2008
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
>
>
More information about the GEM-dev
mailing list