Giter Club home page Giter Club logo

Comments (5)

dfrg avatar dfrg commented on September 1, 2024

Thanks for reporting this. The intent behind separating surface and device creation is to support multiple windows (which may come and go, particularly in UI contexts) that can share resources on a single device. If the current design is failing on dual GPU setups, it’s definitely something that we need to address even if that makes the API less pleasant.

I am curious about the error message. Is it general surface incompatibility or is the format (we unconditionally choose Bgra8Unorm) incompatible?

from vello.

rosefromthedead avatar rosefromthedead commented on September 1, 2024

The error message is Error in Surface::configure: surface does not support the adapter's queue family, so it seems not to be pixel format, but idk how to check.

from vello.

rosefromthedead avatar rosefromthedead commented on September 1, 2024

IMO it would be good to have error handling at surface creation time, to request an adapter that is compatible with the new surface if the current adapter is not, and then continue using both adapters for their respective surfaces. This means that if I have 2 cards with 1 display each then my app can draw to surfaces on both displays simultaneously without incompatibility issues, which might not be possible if vello only keeps one adapter around. Helpfully, it also solves the original problem :P

Here's hoping it's not too hard to add multi-adapter support?

from vello.

dhardy avatar dhardy commented on September 1, 2024

Just a little note, I had a similar report recently, and while at first glance use of a compatible_surface to ensure compatibility may appear a good idea, my conclusion was that this only really does anything for users with multiple GPUs (in the reporter's case, Intel iGPU + NVidia discrete graphics). The better solution, for a general purpose GUI, is to make the surface compatible with as many adapters as possible (including old Intel iGPUs).

from vello.

rosefromthedead avatar rosefromthedead commented on September 1, 2024

Looks like you did that by using the fifo present mode, but vello was already using that before my change, and still didn't work.

FWIW if I "remove" my nvidia vulkan driver, vello works fine (albeit very slowly) regardless of Wayland, X11, #227 or no #227. Maybe that's the bigger problem - wgpu is selecting the nvidia driver very aggressively. Even with PowerPreference::LowPower I can't get it to ignore the nvidia device.

from vello.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.