Texture Tools SDK crash (low-level C API)

Gaming and Visualization Technologies General Topics and Other SDKs
1

I am using the Texture Tools SDK from C, using the low-level API. This is what I am doing so far:

NvttRefImage nvtt_image = {
.data               = linear_rgba,
.width              = width,
.height             = height,
.depth              = 1,
.num_channels       = 4,
.channel_swizzle    = {NVTT_ChannelOrder_Red, NVTT_ChannelOrder_Green, NVTT_ChannelOrder_Blue, NVTT_ChannelOrder_Alpha},
.channel_interleave = true,
};

int num_tiles;
NvttCPUInputBuffer* nvtt_input_buffer = nvttCreateCPUInputBuffer(&nvtt_image, NVTT_ValueType_UINT8, 1, 4, 4, 1, 1, 1, 1, NULL, &num_tiles);

u32   out_size = width * height;
void* output   = tallocate_safe(out_size);

nvttEncodeBC7CPU(&nvtt_input_buffer, false, true, output, false, false, NULL);
nvttDestroyCPUInputBuffer(&nvtt_input_buffer);

The Encode function crashes, and I am suspecting it might be because I am running on an old computer (dating back to 2014 or so), but I cannot confirm it (as far as I can tell, I am using the API correctly here, but who knows). As you can see, I am not using the GPU for compression, I am telling the library to use the CPU. So, assuming I am correctly using the API, could the old CPU be the culprit here?

More info:

output is a piece of memory aligned on 16 bytes (I tried allocating it with malloc to make sure and it does not make a difference).

The debugger reports “access violation reading address 0xffffffffffffffff”.
I am using the DLL from the SDK folder, nvtt30205.dll
CPU: Intel Ivy Bridge, with SSE 4.2, SSSE 3 and AVX (no FMA)
OS: Windows 10

Here is the call stack as viewed in WinDbg:

image
image356Ă—168 2.08 KB

2

Thanks @miketearon ! The calling code looks OK to me at first glance; it’s similar enough to our sample C code. That call stack is certainly unusual – there shouldn’t be a way for nvtt_encode to call toXenonSrgb– but it might be that WinDbg is only showing locations relative to exported functions.

To check two quick things:

Thanks!

3

All right, I tested both and they work fine. I then proceeded to make a small repro on my end and I realised my mistake: I am passing the address of the CPU input buffer handle instead of passing the handle directly. I fixed that and everything is working as expected, so I was not using the API correctly after all. Thank you for the swift reply anyway!

1 Like
4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.