Re: Input texture types / Cache and copy
Re: Input texture types / Cache and copy
- Subject: Re: Input texture types / Cache and copy
- From: Darrin Cardani via Pro-apps-dev <email@hidden>
- Date: Wed, 13 May 2020 09:59:42 -0700
Bret,
There’s no way to force the textures to be 32-bit per channel so you’ll need to
copy them to a 32-bit per channel texture on the GPU, or download them to the
CPU and convert there.
For what it’s worth, if you don’t mind using some C++, I think the OpenEXR
library has what you need to operate directly on 16-bit half float data on the
CPU. It might save you some hassle.
Darrin
> On May 12, 2020, at 7:54 AM, Bret Battey via Pro-apps-dev
> <email@hidden> wrote:
>
> Hi ProAppsDev,
>
> Continuing my plugin conversion from OpenGL to Metal in FxPlug 4.
>
> My plugin unfortunately requires copying the input texture to RAM in order to
> support a special search/crawl process on the RGB data. In the OpenGL
> version, I used glReadPixels to request GL_FLOAT data and so built my crawl
> code around the processing of floats.
>
> I notice that the input texture in my FxPlug 4 version is reading
> MTLPixelFormatRGBA16Float. So it is half-float, which Obj C is not in a ready
> position to deal with elegantly. I notice that the example MTLDeviceCache
> code is written to suggest that RBGA32Float might also be received. It would
> be helpful to know which texture pixel formats might come in to the plugin
> and why. Seem unlikely, but is there any way to force the input texture to
> come in as 32Float?
>
> If not, seems my most efficient conversion from half to float will be to draw
> the input texture to a 32Float texture and then do a Metal GetBytes from that.
>
> I’m testing doing that using the Brightness example, using a
> MTLPixelFormatRGBA32Float pixel format when setting up the Device Cache
> (instead of querying the input pixel format), creating a new
> MTLPixelFormatRGBA32Float texture to target and setting up the pipeline
> accordingly. So far no joy – though hard to assess the issue w/o a Metal
> debugger available. I’m just wondering if I’m missing something in the nature
> of the Metal Device Cache design that might preclude me doing this… (I
> haven’t yet tried doing the whole thing manually without using the Metal
> Device Cache.)
>
> Thanks,
> -=Bret
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Pro-apps-dev mailing list (email@hidden
> <mailto:email@hidden>)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden