Input texture types / Cache and copy
Input texture types / Cache and copy
- Subject: Input texture types / Cache and copy
- From: Bret Battey via Pro-apps-dev <email@hidden>
- Date: Tue, 12 May 2020 14:54:35 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dmu.ac.uk; dmarc=pass action=none header.from=dmu.ac.uk; dkim=pass header.d=dmu.ac.uk; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z4V0hwgng9xAfOjxn0MAShwFZn0rlKYR+Auv3yUXock=; b=dGFp9dVSgenJeJll2y9C8w5lMJB3UUpriEapy5rjzEplfOSxdMbJ5oyo4gmGq1h9+WCt7O+p4ifC3a644+mB1I+Act4kf7jvuwSNKQaf7HiFtfTwZyz7oOpS/UNlM7eNA50XdH7ho6OrbX5z6/bo4YReEIGDUxJPTiVcPk9hSH1QSWZpJY4jlB6Yg5pKEi1t/SPQX63PT+ooKgGSlLK1s4WqvjQkbc+lF1GYCAGYxXTsV/LDJ9vRVmHZUo71uYL5jtEMfQYwH2qKGrZbPzSlqJJ3sxKUGDG628E96z7nhz5PavLDxGo14RkFq9R4w1Tjb9xeIaM/kLVHHoco0j/cHg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B3O5uoU0v00+gSS/+ulV3ZZfACJeh4N650j6NY4yTsEqVMcI0m3qL8xgfcc76SJFG2FNkb8o/EHPb7ZoIAr3IEL/gJj9zUovHNtOGRWrwyv7k1uT6cfpuTfciUHVkPBhOykZ9gmBMBhI8XIbrrBr5XyMnBPO9d+O94DLRSoIrjUueS6togljgcUsvSRRLtJ6SfkvNJJrb+lEdS+pQlMTMTW/0BE6lNk9iDP1YTrHQUgwEBJSCbl1VPrVGdISw/QoMauHBa8XZ517SLC6Roio5+W8dGL+ArWEcJEF4Fk8KKns4XrB0nz8xFixjPpQkgLNSWLfStrdiroo+yDHBou0hA==
- Thread-topic: Input texture types / Cache and copy
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)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden