Introduce enum llama_ftype

[sw]

As discussed in #678, this introduces enum llama_ftype to llama.h which represents the various file types used by llama.cpp

The goal is to improve maintainability of the code by not having integer literals in various places. I hope I didn't miss one.

I used the names and comments from @comex's pending changes to the Python scripts in #545. I have not touched the scripts so as not to cause conflicts with their work.

[prusnak]

How hard is it to change name of this field? This is a private struct, so should be easy, no?

[sw]

Shouldn't be a problem; I just didn't touch any variable names because I didn't know the intended meaning e.g. of the i in itype. Shall I rename f16 to ftype and print a user-friendly string?

fprintf(stderr, "%s: ftype   = %s\n", __func__, ftype_str[hparams.ftype]);

Hopefully no-one tries to parse the stderr outputs, otherwise this might break that. I might do the same for type 3 lines further down.

[comex]

Thumbs-up from me on adding names. But I’d argue that the file type field (f16 in the file header) and tensor type field (ftype in the tensor header) should be two different enums. For example, file type 3 represents what I called ‘mostly’ Q4_1, but tensor type 3 means that that particular tensor is (entirely) Q4_1. A file with file type 3 has a mix of tensor types 0 (F32) and 3 (Q4_1). I made this dissonance somewhat worse by adding file type 4, which has no tensor type equivalent; those files have a mix of tensor types 0 (F32), 1 (F16), and 3 (Q4_1).

In the long run I’d like to see llama.cpp scrap the file type field entirely in favor of just using the tensor type and size fields to initialize the ggml tensor metadata.

[sw]

@comex :

But I’d argue that the file type field (f16 in the file header) and tensor type field (ftype in the tensor header) should be two different enums.

You're right. So actually ftype should be renamed to ttype or some such, and f16 should be renamed to ftype. No wonder I was confused...

So there would be another enum, but should that be public?

    enum llama_ttype {
        LLAMA_TTYPE_F32  = 0,
        LLAMA_TTYPE_F16  = 1,
        LLAMA_TTYPE_Q4_0 = 2,
        LLAMA_TTYPE_Q4_1 = 3,
    };

We might want to make enum ggml_type match this, assuming that one's not written to the file. Which it isn't AFAICT.

I'm not sure about the naming - the t and f are too visually similar, so maybe we should write it out.

[comex]

We might want to make enum ggml_type match this, assuming that one's not written to the file. Which it isn't AFAICT.

It's not written to the file, so that might be a good idea. No strong opinions.

[sw]

@comex: Will this conflict with your plans in #711 (comment) ? You said you want to get rid of f16, I think that's a good idea, so I might close this to avoid conflicts.

[comex]

Even after my change makes the core loading path not care about file type, there will still be some uses, like in the quantization code (which has to accept a file type as an argument and then write it to the file header). So a change like this would still be useful, and I’ll deal with any merge conflicts. However, I still wouldn’t recommend merging this as-is, for the reason I mentioned before.

[sw]

I decided to just use ggml_type and change that to match the numbering in the files. I added initializer designations to the arrays in ggml.c that didn't already have them. This should avoid mixups in the future.