erk- / genfut Goto Github PK

After creating a Futhark context with the C function
futhark_context_new(), the caller must immediately call
futhark_context_get_error() to determine whether initialisation
succeeded. Only if futhark_context_get_error() returns NULL
should the context be used.

Currently in FutharkError::new the error string retrieved is not freed, but it should be according to the futhark docs

At the C API level, freeing a Futhark value can also return an error
code. This is not exposed in the Rust code, where the return code of
the freeing functions is never checked. This is likely because the
implicit resource management implied by the Drop trait is
incompatible with checking deallocations for errors. Futhark has no
documented reason for why deallocation should ever fail, and in
practice it will only occur due to compiler bugs, or perhaps driver or
hardware malfunction, and never under normal circumstances. Yet, it
would be better to check the error code, and perform a Rust panic in
the event of deallocation error.

Futhark now have a machine readable manifest which would be better to generate entry points from than scraping the generated C code with regex.

https://futhark.readthedocs.io/en/stable/c-api.html#manifest

This is a tracking issue for offering better support for the Futhark C-API

Configuration

• futhark_context_config_set_debugging
• futhark_context_config_set_profiling
• futhark_context_config_set_logging
• futhark_context_config_set_tuning_param
• futhark_get_tuning_param_count
• futhark_get_tuning_param_name
• futhark_get_tuning_param_name
• futhark_get_tuning_param_class
• futhark_context_config_set_cache_file

Context

• futhark_context_pause_profiling
• futhark_context_unpause_profiling
• futhark_context_get_error
• futhark_context_set_logging_file
• futhark_context_report
• futhark_context_clear_caches

Opaque values

• futhark_store_opaque_foo
• futhark_restore_opaque_foo

GPU

• futhark_context_config_set_device

OpenCL

• futhark_context_config_set_platform
• futhark_context_config_select_device_interactively
• futhark_context_new_with_command_queue
• futhark_context_get_command_queue

Exotic

• futhark_context_config_set_default_group_size
• futhark_context_config_set_default_num_groups
• futhark_context_config_set_default_tile_size
• futhark_context_config_dump_program_to
• futhark_context_config_load_program_from

Multicore

• context_config_set_num_threads

In the generated Rust code that copies Futhark arrays to CPU
memory, the error value returned by the "values" function is not checked.

Whenever I invoke the genfut build script from the readme, I get an empty 'lib' folder lingering around in my crate root. Is that intentional?

Currently we only generate a single backend for a given futhark file, but there is nothing that should make it impossible to generate multiple. At the moment it will not work since we use features but that will be resolved by #31.

So to bring this change to frutition we need to have different names for each backend and then be able to select which to link and use at compile time in the generated project.

The implementation of FutharkContext does not at any point call
futhark_context_free() or futhark_context_config_free(). This
means that the actual Futhark context object is not freed when the
FutharkContext Rust object is destroyed. GPU resources may thus be
leaked until the process ends entirely and they are reclaimed by the
operating system.

I recommend adding an implementation of the Drop trait for
FutharkContext, which should call futhark_context_free() and
futhark_context_config_free() (in that order). If this is done,
then the implementation of the Copy and Clone
traits should probably be removed.