microsoft / microsoft/TRELLIS

postprocessing_utils.to_glb function does not finish its execution. [stdout.read()]

Open
#292 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
13.7k
Forks
1.3k
PR merge metrics
No merged PRs in 30d

Description

In example_text.py script, the postprocessing_utils.to_glb function doesn't terminate its execution. The code runs until

# mesh postprocess
    vertices, faces = postprocess_mesh(
        vertices, faces,
        simplify=simplify > 0,
        simplify_ratio=simplify,
        fill_holes=fill_holes,
        fill_holes_max_hole_size=fill_holes_max_size,
        fill_holes_max_hole_nbe=int(250 * np.sqrt(1-simplify)),
        fill_holes_resolution=1024,
        fill_holes_num_views=1000,
        debug=debug,
        verbose=verbose,
    )

Going into the definition of postprocess_mesh function in postprocessing_utils.py, the function is executed until

vertices, faces = _fill_holes(
            vertices, faces,
            max_hole_size=fill_holes_max_hole_size,
            max_hole_nbe=32, # max_hole_nbe=fill_holes_max_hole_nbe,
            resolution=32, #resolution=fill_holes_resolution,
            num_views=10,#num_views=fill_holes_num_views,
            debug=debug,
            verbose=verbose,
        )

Going into the definition of _fill_holes function in postprocessing_utils.py, the function is executed until
rastctx = utils3d.torch.RastContext(backend='cuda')

Going into the definition of RastContext constructor in utils3d.torch.rasterization.py, the function is executed until
self.nvd_ctx = dr.RasterizeCudaContext(device=device)

Going into the definition of RasterizeCudaContext constructor in nvidiffrast.torch.ops.py, the function is executed until
self.cpp_wrapper = _get_plugin().RasterizeCRStateWrapper(cuda_device_idx).
_get_plugin() function doesn't terminate.

Going into the definition of _get_plugin() function in nvidiffrast.torch.ops.py, the function is executed until
torch.utils.cpp_extension.load(name=plugin_name, sources=source_paths, extra_cflags=common_opts+cc_opts, extra_cuda_cflags=common_opts+['-lineinfo'], extra_ldflags=ldflags, with_cuda=True, verbose=False)

Going into the definition of load function in torch.utils.cpp_extension.py, the code executes to the end. The return statement calls the function _jit_compile.

Going into the definition of _jit_compile in torch.utils.cpp_extension.py, the function is executed until

_write_ninja_file_and_build_library(
                        name=name,
                        sources=sources,
                        extra_cflags=extra_cflags or [],
                        extra_cuda_cflags=extra_cuda_cflags or [],
                        extra_ldflags=extra_ldflags or [],
                        extra_include_paths=extra_include_paths or [],
                        build_directory=build_directory,
                        verbose=verbose,
                        with_cuda=with_cuda,
                        is_standalone=is_standalone)

Going into the definition of _write_ninja_file_and_build_library function in torch.utils.cpp_extension.py, the function runs 3 subprocesses (completed successfully), and then execution continues until

subprocess.run(
            command,
            stdout=stdout_fileno if verbose else subprocess.PIPE,
            stderr=subprocess.STDOUT,
            cwd=build_directory,
            check=True,
            env=env)

Going into the definition of run function in python3.10.subprocess.py, the function is executed until
tdout, stderr = process.communicate(input, timeout=timeout).

Going into the definition of communicate function in the same .py script, the function is executed until
stdout = self.stdout.read().
Unlike the other 3 subprocesses, this subprocess blocks on the read statement and I don't know what is causing it and what to do.

Do you have any idea what this subprocess does and how to fix it?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with example_text.py and trace postprocessing_utils.py through utils3d.torch.rasterization.py and nvidiffrast.torch.ops.py, then inspect the torch.utils.cpp_extension.load build invoked by _get_plugin(). Reproduce the to_glb call and determine why the compilation subprocess remains blocked; done means the plugin build completes and to_glb returns.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, pytorch
Domain
build-system, computer-graphics
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.