Hotfix the default backend issue

Description

Previous policy regarding the backend management in the PTQ was to set the new nodes backends to their parent ones.

While it looks like a valid approach, it has two caveats :

• Firstly, the parent may not have any backend (like for example the Concat nodes) which causes a registrar issue.
• Secondly, the whole graphView backend is overwritten multiple times in the PTQ pipeline so the information about the original parent backend is in fact lost.

In absence of a better solution, we propose (for now) to set the new nodes backends to cpu by default, and to overwrite the whole graphView backend if useCuda is set to true.

added Fix 🔥🔥 StatusReview Ready labels

requested review from @mick94

assigned to @bhalimi

Regarding point 1, I suggest to create a more sophisticated method that explores the parents or childs until it finds a suitable backend. In case of Concat for example, it would go on and check the Concat paernts...

Furthermore, we should get ride of useCuda argument!

In that case I would propose a recursive design of that sort :

static std::string determineBackend(std::shared_ptr<Aidge::Node> node)
{
    std::string backend = node->getOperator()->backend();

    if (backend != "")
        return backend;
    else 
    {
        // gather the parent backends

        std::set<std::string> parentBackends;
        for (auto parent : node->getParents())
            parentBackends.insert(determineBackend(parent)); // it always answers a non empty value !

        // check if we have two or more different backends gathered

        if (parentBackends.size() > 1) 
        {
            Log::warn(" Unable to determine backend of node {} due to conflicting parent ones !");
            return (*parentBackends.begin());
        }
        
        // if all parents have the same backend return it

        if (parentBackends.size() == 1) 
            return (*parentBackends.begin());
    }
}

added 1 commit

• 302ebd03 - draft the determineBackend() routine

Compare with previous version

@olivierbichler If we have multiple backend tensor connected to an operator shouldn't we raise an error?

I think this is related to the talks we add about transmiters when we were specifying Aidge. If we change backend inside the graph we need a conversion node since no opeartor should be able to handle multiple backend...

No, this is possible. It depends on the operator implementation. Most CUDA operator implementations handle multiple backend input and convert to CUDA internally.

It works for CUDA but not the over way arround! I think it would be better that implementation does not convert input implicitly as it would create an obfuscated mecanic to the user. Knowing which operator can convert to which backend etc ... I would be in favor of adding an explicit convert operator in order to enforce a uniform backend for the input of each operators.

added 1 commit

• 2e21e5dd - make use of determineBackend()

Compare with previous version

I'm not reviewer... Please, change with Olivier

requested review from @olivierbichler and removed review request for @mick94

Lets go with that!

approved this merge request

mentioned in commit f2713d00

merged

mentioned in issue #69 (closed)

I check the good behaviour of the fix with a Yolo V3 and the concat layer (operator without banckend !)

changed milestone to %aidge v0.6.0