GPU support

[xmonader]

from a very highlevel view, to reduce complexity around GPU support the current proposal is we only support GPU for dedicated nodes, and we don't allow the the farmers to get farming rewards for it, but they can define the billing rate on the chain by defining pairs of GPU/Price

The suggested distribution should be (can still be fine-tuned)

• 80% to the farmer
• 10% Threefold
• 10% Burnt

Tasks

Some research has been done about GPU support before here

• ZOS changes Implement GPU support zos#1972
  • Node need to expose to the world (over chain) that it has a GPU
  • A ZMachine deployment can ask for a GPU
    • Only allow if the node is dedicated
    • Only one ZMachine can has this enabled (gpu can't be shared)
  • Check ubuntu flists (create a new one?) that has Radeon drivers
• TFChain changes
  • Allow farmers to set extra fee on its nodes Allow farmer to set extra fee on its nodes tfchain#725
  • Nodes on the chain with GPUs has be querable Nodes on the chain with GPUs has be querable tfchain#737
• Tooling/UI
  • golang client: GPU support in client tfgrid-sdk-go#164
  • terraform terraform GPU support terraform-provider-grid#660
  • grid-cli GPU support in tf-grid-cli tfgrid-sdk-go#165
  • typescript: GPU support in the client tfgrid-sdk-ts#464
  • gpu cost in calculators: GPU cost price in calculators tfgrid-sdk-ts#466
  • gpu support in explorer GPU support in explorer tfgrid-sdk-ts#465
  • gpu support in statistics website gpu support in statistics website tfgrid-sdk-ts#492
  • indexer node gpu info indexer tfgrid-sdk-go#209 (possibly won't be implemented)

[delandtj]

where is the 'proposal' ?

[muhamadazmy]

Story on circles

[DylanVerstraete]

Some very important remarks before we can implement this:

1. Pricing policies can be extended to also include pricing for GPU resources, this needs to be defined how much such resources cost per hour.

2. Changing distribution rules for this specific feature is technically impossible, the distribution scheme is defined on the pricing policy and since we will not implement custom pricing policies that a farmer can set we should avoid creating a workaround in the code (will result in more error prone code in general).

Before we implement custom pricing policies that farmers can set we need to first define new tokenomics. The general idea is that farmers can set their own pricing but should also be rewarded for utilisation. Setting a custom price without distrubting rewards for utilisation back to farmer can lead to:

• A farmer setting a very high price and thus not wanting to attract workload (to keep energy consumption low)
• A farmer setting a very low price so Threefold gets less revenue from this farmer hosting workloads
• Generally no interest in setting a price at all since the farmer is not rewarded for doing that

[muhamadazmy]

@DylanVerstraete

• For the GPU price, this can be set to 0 until we decide how much it is.
• For the custom pricing policy don't worry about it now, this is for later, and I already started a discussion on the tfchain repo. I understand the part where techonomics need to be changed, feel free to put all your thoughts on the discussion

[DylanVerstraete]

Well, the story also indicates a different distribution scheme @muhamadazmy

[DylanVerstraete]

It's either we use default pricing for GPU and default distribution scheme or we redefine tokenomics, allow custom pricing and allow custom distribution schemes.

[muhamadazmy]

IMHO re-defining tokenomics (although I am not against it) is out of scope of this story for the following reasons, and I am sorry but I am looking into this from a 100% technical point of view to unlock the issue:

• We are not allowing farmers to set their own prices yet (or may be never)
• What we need to have is the same pricing policy changed a little bit to support
  • default distribution
  • custom distribution if dedicated + gpu . IMHO this should not be a problem even with some type change migration should not be a problem because we have only one pricing policy.

We can then discuss in the other issues the tokenmoics

[DylanVerstraete]

I know that without custom pricing it's fairly easy to do but the story mentions:

but they can define the billing rate on the chain by defining pairs of GPU/Price

Which requires changes which can only be implemented if we allow the farmer to set custom pricing for their farm.

I can also read in the story that it mentions that custom pricing will not be supported for now but then the story description needs to change and approved by stakeholders.

[DylanVerstraete]

I was also just pointing out that allowing farmers to set custom pricing also would require changes in the tokenomics, I never suggested that it would be part of this issue.

[despiegk]

not custom pricing for farm, just a price per node, how much work is this

[DylanVerstraete]

@despiegk Currently pricing is linked to a farm and all farms have the default threefold pricing policy. Having pricing linked to node a node still can cause following issues:

• A farmer setting a very high price and thus not wanting to attract workload (to keep energy consumption low)
• A farmer setting a very low price so Threefold gets less revenue from this farmer hosting workloads
• Generally no interest in setting a price at all since the farmer is not rewarded for doing that

[despiegk]

On Thu, Jun 1, 2023 at 6:00 PM Dylan Verstraete ***@***.***> wrote: @despiegk <https://github.com/despiegk> Currently pricing is linked to a farm and all farms have the default threefold pricing policy. Having pricing linked to node a node still can cause following issues: - A farmer setting a very high price and thus not wanting to attract workload (to keep energy consumption low) is not an issue, and why would he do that, put HW in he doesn't use, there

is no farming reward for GPU the price is for the GPU part of the node, not for the rest of the node

- A farmer setting a very low price so Threefold gets less revenue from this farmer hosting workloads same here, not an issue, low price means he doesn't get enough money to

pay for HW and power, why would he do that

- Generally no interest in setting a price at all since the farmer is not rewarded for doing that

??? I think we are talking next to each other here,

…

— Reply to this email directly, view it on GitHub <#1392 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABN6FVE5OLSVQZXOI5V3Z3LXJCVB7ANCNFSM6AAAAAAU2DQPXQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- ------------------------ Kristof De Spiegeleer +971525609014 +201206927877 +32 475405474 skype: despiegk

[renauter]

Hi all
Here is a first draft of specs for GPU support on TFChain:

• GPU support on TFChain tfchain#724

Feel free to review and comment

[despiegk]

i commented there, we keep on going a too complicated route, please let simplify a lot and execute

we don't need pricing policy, we don't need to even specify that its for a GPU

[DylanVerstraete]

Updated the story to reflect latest state, all work regarding tfchain is tracked in threefoldtech/tfchain#725

[muhamadazmy]

Blocked on this threefoldtech/tfchain#737

[xmonader]

It's unblocked now
quoting Azmy

We agreed to add flags to the node but just boolean gpu: true which means the Client can build a short list with nodes that has GPus and free for rent but still need to query the nodes over rmb with the details of the hardware they have/provide.
May be a UI in the dashboard can have a find nodes for rent for example that has a wizard to spot and rent the node that is suitable for needs. Once nodes are rented can be used to deploy workloads

[xmonader]

To keep the issue updated, the indexer is already done threefoldtech/tfgrid-sdk-go#209 , remaining to remove the gpu info from tfchain and graphql

[A-Harby]

Closing issue as done,
GPU test suite is created, and all the tasks mentioned are verified and closed.