prompt: You will be provided with a partial code base and an issue statement explaining a problem to resolve.
  <issue>
  Enable multiprocessing when testing with GPU and support distributed strategies in the tests.
  **Describe the feature and the current behavior/state.**
  
  Here I'm not going to discuss the bazel case as it's much more complicated to handle, and we currently advertize using pytest anyway to run the tests. We can of course make sure everything is compatible though.
  
  This revamping of gpu testing has multiple objectives:
  
  * The tests should behave the same weither the contributor has a gpu or not. Meaning we shouldn't run all the tests on a gpu just because a gpu is available, otherwise it hurts reproducibility.
  * The test suite should be able to run with multiple workers in kokoro or when a user has multiple gpus. Pytest should use all gpus visible by the main process.
  * We need to support testing with distributed strategies. Currently it doesn't work. A fix has been started in #1209 but we need to update it for pytest. 
  * Making the whole thing simple to use and to maintain. Notably, we would get rid of this file: https://github.com/tensorflow/addons/blob/master/tools/testing/parallel_gpu_execute.sh which is quite hard to work on.
  
  
  To do all that, here is my proposal:
  
  Stuff to know: 
  * Pytest-xdist uses multiprocessing to run the tests, not multithreading. 
  * 2 environement variables are available in each of the workers to identify them. https://github.com/pytest-dev/pytest-xdist#identifying-the-worker-process-during-a-test
  
  
  ### Test workers
  Suppose we have a machine with 10CPUs and 4 GPUs, 10 processes will start to run the test suite. Workers 0 to 3 will have ownership of one GPU each (we can use CUDA_VISIBLE_DEVICES to enforce that, but I'm not even sure that's needed with the proposed implementation). Workers 4 to 9 will have no gpu available.
  
  ### Virtual devices
  Each of those processes, when starting, will split their physical device into 2 virtual device. Tests that just need to run on gpu will use the first of those virtual devices. Processes which need to test distributed strategies will use the two of them. We assume here that 2 virtual devices are enough to test distributed strategies.
  
  ### Impact on the contributors:
  For this whole machinery to work, we need to know which test needs to run on CPU, GPU, or in distributed strategies. To do that we'll use pytest markers: `@pytest.mark.....`
  
  * By default, if no marker is found, the test will run on CPU: `with device("CPU:0")`. It's equivalent to 
  `@pytest.mark.run_on(["cpu"])`.
  * To run with gpu only: `@pytest.mark.run_on(["gpu"])`.
  * To run on the cpu and gpu: `@pytest.mark.run_on(["cpu", "gpu"])` (test runs twice)
  * To run in within a distributed strategy `@pytest.mark.run_on(["distributed strategy"])`. (runs once here).
  * To run with everything `@pytest.mark.run_on(["cpu", "gpu", "distributed strategy"])`
  * To make crazy stuff, and not run the test in any device scope: `@pytest.mark.no_device_scope`. Then the contributor can do whatever he/she wants in the test.
  
  Of course, if no gpu is available, we just skip the tests needing a distribution strategy or the gpu. Contributors who handle the devices manually have to make sure to skip manually the test if the gpu is used.
  
  Since gpu are often the scarsest ressource (nb gpus << nb cpus), tests needing the gpu will also be marked with `@pytest.mark.tryfirst` to ensure that we don't have workers starvation at the end (to get maximum speed).
  
  To implement that, we need first to convert all tests to pytest (as opposed to unittest) it's currently 80% done and thanks a lot @autoih for putting a LOT of work into that.
  
  
  
  **Relevant information**
  - Are you willing to contribute it (yes/no): yes
  - Are you willing to maintain it going forward? (yes/no): yes
  - Is there a relevant academic paper? (if so, where): no
  - Is there already an implementation in another framework? (if so, where): no
  - Was it part of tf.contrib? (if so, where): no
  
  **Which API type would this fall under (layer, metric, optimizer, etc.)**
  
  Testing
  
  **Who will benefit with this feature?**
  
  Contributors with gpu, CI.
  
  **Any other info.**
  
  I believe that the implementation will first go in tensorflow addons because we have 4 GPUs available in the CI. Later on when it's stable we can split it from tensorflow addons and make it a separate pytest plugin with a public API.
  
  Comments welcome. Especially from @Squadrick , @hyang0129 , @seanpmorgan since I'm not a ninja of tf.device.
  
  </issue>
  <code>
  [start of tensorflow_addons/conftest.py]
  1 from tensorflow_addons.utils.test_utils import (  # noqa: F401
  2     maybe_run_functions_eagerly,
  3     pytest_make_parametrize_id,
  4     data_format,
  5     set_seeds,
  6     pytest_addoption,
  7     set_global_variables,
  8     pytest_configure,
  9     device,
  10     pytest_generate_tests,
  11 )
  12 
  13 # fixtures present in this file will be available
  14 # when running tests and can be referenced with strings
  15 # https://docs.pytest.org/en/latest/fixture.html#conftest-py-sharing-fixture-functions
  16
  [end of tensorflow_addons/conftest.py]
  </code>
  
  I need you to solve this issue by generating a single patch file that I can apply directly to this repository using git apply. Please respond with a single patch file in the following format.
  <patch>
  diff --git a/file.py b/file.py
  --- a/file.py
  +++ b/file.py
  @@ -1,27 +1,35 @@
   def euclidean(a, b):
  -    while b:
  -        a, b = b, a % b
  -    return a
  +    if b == 0:
  +        return a
  +    return euclidean(b, a % b)
   
   
   def bresenham(x0, y0, x1, y1):
       points = []
       dx = abs(x1 - x0)
       dy = abs(y1 - y0)
  -    sx = 1 if x0 < x1 else -1
  -    sy = 1 if y0 < y1 else -1
  -    err = dx - dy
  +    x, y = x0, y0
  +    sx = -1 if x0 > x1 else 1
  +    sy = -1 if y0 > y1 else 1
   
  -    while True:
  -        points.append((x0, y0))
  -        if x0 == x1 and y0 == y1:
  -            break
  -        e2 = 2 * err
  -        if e2 > -dy:
  -            err -= dy
  -            x0 += sx
  -        if e2 < dx:
  -            err += dx
  -            y0 += sy
  +    if dx > dy:
  +        err = dx / 2.0
  +        while x != x1:
  +            points.append((x, y))
  +            err -= dy
  +            if err < 0:
  +                y += sy
  +                err += dx
  +            x += sx
  +    else:
  +        err = dy / 2.0
  +        while y != y1:
  +            points.append((x, y))
  +            err -= dx
  +            if err < 0:
  +                x += sx
  +                err += dy
  +            y += sy
  +
  +    points.append((x, y))
       return points
  
  </patch>
golden_diff: diff --git a/tensorflow_addons/conftest.py b/tensorflow_addons/conftest.py
  --- a/tensorflow_addons/conftest.py
  +++ b/tensorflow_addons/conftest.py
  @@ -8,6 +8,7 @@
       pytest_configure,
       device,
       pytest_generate_tests,
  +    pytest_collection_modifyitems,
   )
   
   # fixtures present in this file will be available
  
verification_info: {"golden_diff": "diff --git a/tensorflow_addons/conftest.py b/tensorflow_addons/conftest.py\n--- a/tensorflow_addons/conftest.py\n+++ b/tensorflow_addons/conftest.py\n@@ -8,6 +8,7 @@\n     pytest_configure,\n     device,\n     pytest_generate_tests,\n+    pytest_collection_modifyitems,\n )\n \n # fixtures present in this file will be available\n", "issue": "Enable multiprocessing when testing with GPU and support distributed strategies in the tests.\n**Describe the feature and the current behavior/state.**\r\n\r\nHere I'm not going to discuss the bazel case as it's much more complicated to handle, and we currently advertize using pytest anyway to run the tests. We can of course make sure everything is compatible though.\r\n\r\nThis revamping of gpu testing has multiple objectives:\r\n\r\n* The tests should behave the same weither the contributor has a gpu or not. Meaning we shouldn't run all the tests on a gpu just because a gpu is available, otherwise it hurts reproducibility.\r\n* The test suite should be able to run with multiple workers in kokoro or when a user has multiple gpus. Pytest should use all gpus visible by the main process.\r\n* We need to support testing with distributed strategies. Currently it doesn't work. A fix has been started in #1209 but we need to update it for pytest. \r\n* Making the whole thing simple to use and to maintain. Notably, we would get rid of this file: https://github.com/tensorflow/addons/blob/master/tools/testing/parallel_gpu_execute.sh which is quite hard to work on.\r\n\r\n\r\nTo do all that, here is my proposal:\r\n\r\nStuff to know: \r\n* Pytest-xdist uses multiprocessing to run the tests, not multithreading. \r\n* 2 environement variables are available in each of the workers to identify them. https://github.com/pytest-dev/pytest-xdist#identifying-the-worker-process-during-a-test\r\n\r\n\r\n### Test workers\r\nSuppose we have a machine with 10CPUs and 4 GPUs, 10 processes will start to run the test suite. Workers 0 to 3 will have ownership of one GPU each (we can use CUDA_VISIBLE_DEVICES to enforce that, but I'm not even sure that's needed with the proposed implementation). Workers 4 to 9 will have no gpu available.\r\n\r\n### Virtual devices\r\nEach of those processes, when starting, will split their physical device into 2 virtual device. Tests that just need to run on gpu will use the first of those virtual devices. Processes which need to test distributed strategies will use the two of them. We assume here that 2 virtual devices are enough to test distributed strategies.\r\n\r\n### Impact on the contributors:\r\nFor this whole machinery to work, we need to know which test needs to run on CPU, GPU, or in distributed strategies. To do that we'll use pytest markers: `@pytest.mark.....`\r\n\r\n* By default, if no marker is found, the test will run on CPU: `with device(\"CPU:0\")`. It's equivalent to \r\n`@pytest.mark.run_on([\"cpu\"])`.\r\n* To run with gpu only: `@pytest.mark.run_on([\"gpu\"])`.\r\n* To run on the cpu and gpu: `@pytest.mark.run_on([\"cpu\", \"gpu\"])` (test runs twice)\r\n* To run in within a distributed strategy `@pytest.mark.run_on([\"distributed strategy\"])`. (runs once here).\r\n* To run with everything `@pytest.mark.run_on([\"cpu\", \"gpu\", \"distributed strategy\"])`\r\n* To make crazy stuff, and not run the test in any device scope: `@pytest.mark.no_device_scope`. Then the contributor can do whatever he/she wants in the test.\r\n\r\nOf course, if no gpu is available, we just skip the tests needing a distribution strategy or the gpu. Contributors who handle the devices manually have to make sure to skip manually the test if the gpu is used.\r\n\r\nSince gpu are often the scarsest ressource (nb gpus << nb cpus), tests needing the gpu will also be marked with `@pytest.mark.tryfirst` to ensure that we don't have workers starvation at the end (to get maximum speed).\r\n\r\nTo implement that, we need first to convert all tests to pytest (as opposed to unittest) it's currently 80% done and thanks a lot @autoih for putting a LOT of work into that.\r\n\r\n\r\n\r\n**Relevant information**\r\n- Are you willing to contribute it (yes/no): yes\r\n- Are you willing to maintain it going forward? (yes/no): yes\r\n- Is there a relevant academic paper? (if so, where): no\r\n- Is there already an implementation in another framework? (if so, where): no\r\n- Was it part of tf.contrib? (if so, where): no\r\n\r\n**Which API type would this fall under (layer, metric, optimizer, etc.)**\r\n\r\nTesting\r\n\r\n**Who will benefit with this feature?**\r\n\r\nContributors with gpu, CI.\r\n\r\n**Any other info.**\r\n\r\nI believe that the implementation will first go in tensorflow addons because we have 4 GPUs available in the CI. Later on when it's stable we can split it from tensorflow addons and make it a separate pytest plugin with a public API.\r\n\r\nComments welcome. Especially from @Squadrick , @hyang0129 , @seanpmorgan since I'm not a ninja of tf.device.\n", "before_files": [{"content": "from tensorflow_addons.utils.test_utils import (  # noqa: F401\n    maybe_run_functions_eagerly,\n    pytest_make_parametrize_id,\n    data_format,\n    set_seeds,\n    pytest_addoption,\n    set_global_variables,\n    pytest_configure,\n    device,\n    pytest_generate_tests,\n)\n\n# fixtures present in this file will be available\n# when running tests and can be referenced with strings\n# https://docs.pytest.org/en/latest/fixture.html#conftest-py-sharing-fixture-functions\n", "path": "tensorflow_addons/conftest.py"}]}