On December 28, 2017 08:24:03 Jason Ekstrand <ja...@jlekstrand.net> wrote:
On December 28, 2017 01:30:11 Kenneth Graunke <kenn...@whitecape.org> wrote:
On Wednesday, December 27, 2017 3:13:42 PM PST Jason Ekstrand wrote:
On December 27, 2017 17:06:43 Kenneth Graunke <kenn...@whitecape.org> wrote:
> On Wednesday, December 27, 2017 12:58:12 PM PST Jason Ekstrand wrote:
>> ---
>> src/intel/tools/aubinator_error_decode.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/intel/tools/aubinator_error_decode.c
>> b/src/intel/tools/aubinator_error_decode.c
>> index d6fbfe0..f0c5b5b 100644
>> --- a/src/intel/tools/aubinator_error_decode.c
>> +++ b/src/intel/tools/aubinator_error_decode.c
>> @@ -350,8 +350,10 @@ read_data_file(FILE *file)
>> uint32_t *data = NULL;
>> int count = ascii85_decode(line+1, &data, line[0] == ':');
>> if (count == 0) {
>> - fprintf(stderr, "ASCII85 decode failed.\n");
>> - exit(EXIT_FAILURE);
>> + fprintf(stderr, "ASCII85 decode of %s at 0x%08"PRIx64"
failed.\n",
>> + sections[sect_num].buffer_name,
>> + sections[sect_num].gtt_offset);
>> + continue;
>> }
>> sections[sect_num].data = data;
>> sections[sect_num].count = count;
>>
>
> What's the rationale, here? At this point, you've got a malformed file.
> What do we gain by supporting invalid file formats?
Because there's a decent chance (I've got multiple files on my laptop that
are this way) that other BOs will decompress ok. I still don't know why
aubinator is failing to decompress things.
--Jason
Are they just from old pre-ascii85 support kernels or something?
Nope, 4.14 or 4.13.
I should be more specific. It's not ascii85 decide that fails, it's zlib
decompression. I have no idea why.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
