[PATCH 2/6] d3dcompiler: Implement D3DGetBlobPart().

Rico Schüller kgbricola at web.de
Mon Sep 20 12:31:01 CDT 2010

Am 20.09.2010 13:09, schrieb Henri Verbeet:
> I think it's close, but not entirely what I had in mind. You can avoid
> both the callback and some of the data copies if you just let
> parse_dxbc() create a list / array of sections. So you'd have
> something like this:
> struct dxbc_section
> {
>      DWORD tag;
>      const char *data;
>      SIZE_T data_size;
> };
> struct dxbc
> {
>      UINT section_size;
>      UINT section_count;
>      struct dxbc_section *sections;
> };
> with parse_dxbc() just calling something like dxbc_add_section()
> instead of chunk_handler(). The sections can just refer to the
> original data in the dxbc blob, it's then the responsibility of the
> caller to either make sure that data stays around for as long as the
> sections are needed or make a copy of the data.
> d3dcompiler_get_blob_part() would then just iterate over all the
> sections and add the relevant ones to a second dxbc struct, which it
> would pass to dxbc_write_blob() afterwards. I don't think
> dxbc_remove_section() is very useful in general, you'll pretty much
> always just want to add sections to a new section list. It's also
> simply unused in your current patch. dxbc_release() should be called
> dxbc_destroy(), you're not doing any reference counting, and the
> naming would be more consistent if you renamed parse_dxbc() to
> dxbc_parse().
Sure that abroach works pretty well for the D3DGetBlobPart() function, 
but you it is a bit ugly to use it for the D3DStripShader(). There you 
have to add some quirks. You would have to parse the dxbc twice to get 
the correct count (could be != count in dxbc original) and then parse 
only the needed blob parts. Therefore I added the dxbc_remove_section() 
function. I've attached all patches so that you could see what 
D3DStripShader() does.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches.7z
Type: application/x-7z-compressed
Size: 13497 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100920/c22c628d/attachment.7z>

More information about the wine-devel mailing list