Re: How to get developer access to mesa gitlab repo ?
This was fine. It's mostly that those requests often get lost in the flood if email traffic coming out of GitLab. Sending an email or pinging on IRC works. You've got access now. ~Faith On September 13, 2023 22:05:12 Feng Jiang wrote: Dear All! I didn't find some tips or instructions in https://docs.mesa3d.org/ . By browsing the site, it looks like you need to submit an issue called 'Mesa Developer Access' and then attach a shortlog. So I tried submitted an issue (https://gitlab.freedesktop.org/mesa/mesa/-/issues/9094), but it didn't get approved, is there a strict number of shortlogs and votes that are required? Any suggestions are greatly appreciated, and I apologize if it's intrusive!
Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
Yeah, this one's gonna hit Phoronix... When we started writing Vulkan drivers back in the day, there was this notion that Vulkan was a low-level API that directly targets hardware. Vulkan drivers were these super thin things that just blasted packets straight into the hardware. What little code was common was small and pretty easy to just copy+paste around. It was a nice thought... What's happened in the intervening 8 years is that Vulkan has grown. A lot. We already have several places where we're doing significant layering. It started with sharing the WSI code and some Python for generating dispatch tables. Later we added common synchronization code and a few vkFoo2 wrappers. Then render passes and... https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024 That's been my project the last couple weeks: A common VkPipeline implementation built on top of an ESO-like interface. The big deviation this MR makes from prior art is that I make no attempt at pretending it's a layered implementation. The vtable for shader objects looks like ESO but takes its own path when it's useful to do so. For instance, shader creation always consumes NIR and a handful of lowering passes are run for you. It's no st_glsl_to_nir but it is a bit opinionated. Also, a few of the bits that are missing from ESO such as robustness have been added to the interface. In my mind, this marks a pretty fundamental shift in how the Vulkan runtime works, at least in my mind. Previously, everything was designed to be a toolbox where you can kind of pick and choose what you want to use. Also, everything at least tried to act like a layer where you still implemented Vulkan but you could leave out bits like render passes if you implemented the new thing and were okay with the layer. With the ESO code, you implement something that isn't Vulkan entrypoints and the actual entrypoints live in the runtime. This lets us expand and adjust the interface as needed for our purposes as well as sanitize certain things even in the modern API. The result is that NVK is starting to feel like a gallium driver. 🙃 So here's the question: do we like this? Do we want to push in this direction? Should we start making more things work more this way? I'm not looking for MRs just yet nor do I have more reworks directly planned. I'm more looking for thoughts and opinions as to how the various Vulkan driver teams feel about this. We'll leave the detailed planning for the Mesa issue tracker. It's worth noting that, even though I said we've tried to keep things layerish, there are other parts of the runtime that look like this. The synchronization code is a good example. The vk_sync interface is pretty significantly different from the Vulkan objects it's used to implement. That's worked out pretty well, IMO. With as complicated as something like pipelines or synchronization are, trying to keep the illusion of a layer just isn't practical. So, do we like this? Should we be pushing more towards drivers being a backed of the runtime instead of a user of it? Now, before anyone asks, no, I don't really want to build a multi-API abstraction with a Vulkan state tracker. If we were doing this 5 years ago and Zink didn't already exist, one might be able to make an argument for pushing in that direction. However, that would add a huge amount of weight to the project and make it even harder to develop the runtime than it already is and for little benefit at this point. Here's a few other constraints on what I'm thinking: 1. I want it to still be possible for drivers to implement an extension without piles of runtime plumbing or even bypass the runtime on occasion as needed. 2. I don't want to recreate the gallium cap disaster drivers should know exactly what they're advertising. We may want to have some internal features or properties that are used by the runtime to make decisions but they'll be in addition to the features and properties in Vulkan. 3. We've got some meta stuff already but we probably want more. However, I don't want to force meta on folks who don't want it. The big thing here is that if we do this, I'm going to need help. I'm happy to do a lot of the architectural work but drivers are going to have to keep up with the changes and I can't take on the burden of moving 8 different drivers forward. I can answer questions and maybe help out a bit but the refactoring is going to be too much for one person, even if that person is me. Thoughts? ~Faith
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
On Mon, Jan 22, 2024 at 7:20 AM Iago Toral wrote: > > Hi Faith, > > thanks for starting the discussion, we had a bit of an internal chat > here at Igalia to see where we all stand on this and I am sharing some > initial thoughts/questions below: > > El vie, 19-01-2024 a las 11:01 -0600, Faith Ekstrand escribió: > > > Thoughts? > > We think it is fine if the Vulkan runtime implements its own internal > API that doesn't match Vulkan's. If we are going down this path however > we really want to make sure we have good documentation for it so it is > clear how all that works without having to figure things out by looking > at the code. That's a reasonable request. We probably won't re-type the Vulkan spec in comments but having differences documented is reasonable. I'm thinking the level of documentation in vk_graphics_state. > For existing drivers we think it is a bit less clear whether the effort > required to port is going to be worth it. If you end up having to throw > away a lot of what you currently have that already works and in some > cases might even be optimal for your platform it may be a hard ask. > What are your thoughts on this? How much adoption would you be looking > for from existing drivers? That's a good question. One of the problems I'm already seeing is that we have a bunch of common stuff which is in use in some drivers and not in others and I generally don't know why. If there's something problematic about it on some vendor's hardware, we should fix that. If it's just that driver teams don't have the time for refactors, that's a different issue. Unfortunately, I usually don't know besides one-off comments from a developer here and there. And, yeah, I know it can be a lot of work. Hopefully the work pays off in the long run but short-term it's often hard to justify. :-/ > As new features are added to the runtime, we understand some of them > could have dependencies on other features, building on top of them, > requiring drivers to adopt more of the common vulkan runtime to > continue benefiting from additional features, is that how you see this > or would you still expect many runtime features to still be independent > from each other to facilitate driver opt-in on a need-by-need basis? At a feature level, yes. However, one of the big things I'm struggling with right now is layering issues where we really need to flip things around from the driver calling into the runtime to the runtime calling into the driver. One of the things I would LOVE to put in the runtime is YCbCr emulation for drivers that don't natively have multi-plane image support. However, that just isn't possible today thanks to the way things are layered. In particular, we would need the runtime to be able to make one `VkImage` contain multiple driver images and that's just not possible as long as the driver is controlling image creation. We also don't have enough visibility into descriptor sets. People have also talked about trying to do a common ray-tracing implementation. Unfortunately, I just don't see that happening with the current layer model. Unfortunately, I don't have a lot of examples of what that would look like without having written the code to do it. One thing I'm currently thinking about is switching more objects to a kernel vtable model like I did with `vk_pipeline` and `vk_shader` in the posted MR. This puts the runtime in control of the object's life cycle and more easily allows for multiple implementations of an object type. Like right now you can use the common implementation for graphics and compute and roll your own vk_pipeline for ray-tracing. I realize that doesn't really apply to Raspberry Pi but it's an example of what flipping the layering around looks like. The other thing I've been realizing as I've been thinking about this over the week-end is that, if this happens, we're likely heading towards another gallium/classic split for a while. (Though hopefully without the bad blood in the community that we had from gallium.) If this plays out similarly to gallium/classic, a bunch of drivers will remain classic, doing most things themselves and the new thing (which really needs a name, BTW) will be driven by a small subset of drivers and then other drivers get moved over as time allows. This isn't necessarily a bad thing, it's just a recognition of how large-scale changes tend to roll out within Mesa and the potential scope of a more invasive runtime project. Thinking of it this way would also give more freedom to the people building the new thing to just build it without worrying about driver porting and trying to do everything incrementally. If we do attempt this, it needs to be done with a subset of drivers that is as representative of the in
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
Jose, Thanks for your thoughts! On Wed, Jan 24, 2024 at 4:30 AM Jose Fonseca wrote: > > I don't know much about the current Vulkan driver internals to have or > provide an informed opinion on the path forward, but I'd like to share my > backwards looking perspective. > > Looking back, Gallium was two things effectively: > (1) an abstraction layer, that's watertight (as in upper layers shouldn't > reach through to lower layers) > (2) an ecosystem of reusable components (draw, util, tgsi, etc.) > > (1) was of course important -- and the discipline it imposed is what enabled > to great simplifications -- but it also became a straight-jacket, as GPUs > didn't stand still, and sooner or later the see-every-hardware-as-the-same > lenses stop reflecting reality. > > If I had to pick one, I'd say that (2) is far more useful and practical. > Take components like gallium's draw and other util modules. A driver can > choose to use them or not. One could fork them within Mesa source tree, and > only the drivers that opt-in into the fork would need to be tested/adapted/etc > > On the flip side, Vulkan API is already a pretty low level HW abstraction. > It's also very flexible and extensible, so it's hard to provide a watertight > abstraction underneath it without either taking the lowest common > denominator, or having lots of optional bits of functionality governed by a > myriad of caps like you alluded to. There is a third thing that isn't really recognized in your description: (3) A common "language" to talk about GPUs and data structures that represent that language This is precisely what the Vulkan runtime today doesn't have. Classic meta sucked because we were trying to implement GL in GL. u_blitter, on the other hand, is pretty fantastic because Gallium provides a much more sane interface to write those common components in terms of. So far, we've been trying to build those components in terms of the Vulkan API itself with calls jumping back into the dispatch table to try and get inside the driver. This is working but it's getting more and more fragile the more tools we add to that box. A lot of what I want to do with gallium2 or whatever we're calling it is to fix our layering problems so that calls go in one direction and we can untangle the jumble. I'm still not sure what I want that to look like but I think I want it to look a lot like Vulkan, just with a handier interface. ~Faith > Not sure how useful this is in practice to you, but the lesson from my POV is > that opt-in reusable and shared libraries are always time well spent as they > can bend and adapt with the times, whereas no opt-out watertight abstractions > inherently have a shelf life. > > Jose > > On Fri, Jan 19, 2024 at 5:30 PM Faith Ekstrand wrote: >> >> Yeah, this one's gonna hit Phoronix... >> >> When we started writing Vulkan drivers back in the day, there was this >> notion that Vulkan was a low-level API that directly targets hardware. >> Vulkan drivers were these super thin things that just blasted packets >> straight into the hardware. What little code was common was small and >> pretty easy to just copy+paste around. It was a nice thought... >> >> What's happened in the intervening 8 years is that Vulkan has grown. A lot. >> >> We already have several places where we're doing significant layering. >> It started with sharing the WSI code and some Python for generating >> dispatch tables. Later we added common synchronization code and a few >> vkFoo2 wrappers. Then render passes and... >> >> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024 >> >> That's been my project the last couple weeks: A common VkPipeline >> implementation built on top of an ESO-like interface. The big >> deviation this MR makes from prior art is that I make no attempt at >> pretending it's a layered implementation. The vtable for shader >> objects looks like ESO but takes its own path when it's useful to do >> so. For instance, shader creation always consumes NIR and a handful of >> lowering passes are run for you. It's no st_glsl_to_nir but it is a >> bit opinionated. Also, a few of the bits that are missing from ESO >> such as robustness have been added to the interface. >> >> In my mind, this marks a pretty fundamental shift in how the Vulkan >> runtime works, at least in my mind. Previously, everything was >> designed to be a toolbox where you can kind of pick and choose what >> you want to use. Also, everything at least tried to act like a layer >> where you still implemented Vulkan but you could le
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
On Wed, Jan 24, 2024 at 12:26 PM Zack Rusin wrote: > > On Wed, Jan 24, 2024 at 10:27 AM Faith Ekstrand wrote: > > > > Jose, > > > > Thanks for your thoughts! > > > > On Wed, Jan 24, 2024 at 4:30 AM Jose Fonseca wrote: > > > > > > I don't know much about the current Vulkan driver internals to have or provide an informed opinion on the path forward, but I'd like to share my backwards looking perspective. > > > > > > Looking back, Gallium was two things effectively: > > > (1) an abstraction layer, that's watertight (as in upper layers shouldn't reach through to lower layers) > > > (2) an ecosystem of reusable components (draw, util, tgsi, etc.) > > > > > > (1) was of course important -- and the discipline it imposed is what enabled to great simplifications -- but it also became a straight-jacket, as GPUs didn't stand still, and sooner or later the see-every-hardware-as-the-same lenses stop reflecting reality. > > > > > > If I had to pick one, I'd say that (2) is far more useful and practical.Take components like gallium's draw and other util modules. A driver can choose to use them or not. One could fork them within Mesa source tree, and only the drivers that opt-in into the fork would need to be tested/adapted/etc > > > > > > On the flip side, Vulkan API is already a pretty low level HW abstraction. It's also very flexible and extensible, so it's hard to provide a watertight abstraction underneath it without either taking the lowest common denominator, or having lots of optional bits of functionality governed by a myriad of caps like you alluded to. > > > > There is a third thing that isn't really recognized in your description: > > > > (3) A common "language" to talk about GPUs and data structures that > > represent that language > > > > This is precisely what the Vulkan runtime today doesn't have. Classic > > meta sucked because we were trying to implement GL in GL. u_blitter, > > on the other hand, is pretty fantastic because Gallium provides a much > > more sane interface to write those common components in terms of. > > > > So far, we've been trying to build those components in terms of the > > Vulkan API itself with calls jumping back into the dispatch table to > > try and get inside the driver. This is working but it's getting more > > and more fragile the more tools we add to that box. A lot of what I > > want to do with gallium2 or whatever we're calling it is to fix our > > layering problems so that calls go in one direction and we can > > untangle the jumble. I'm still not sure what I want that to look like > > but I think I want it to look a lot like Vulkan, just with a handier > > interface. > > Yes, that makes sense. When we were writing the initial components for > gallium (draw and cso) I really liked the general concept and thought > about trying to reuse them in the old, non-gallium Mesa drivers but > the obstacle was that there was no common interface to lay them on. > Using GL to implement GL was silly and using Vulkan to implement > Vulkan is not much better. > > Having said that my general thoughts on GPU abstractions largely match > what Jose has said. To me it's a question of whether a clean > abstraction: > - on top of which you can build an entire GPU driver toolkit (i.e. all > the components and helpers) > - that makes it trivial to figure up what needs to be done to write a > new driver and makes bootstrapping a new driver a lot simpler > - that makes it easier to reason about cross hardware concepts (it's a > lot easier to understand the entirety of the ecosystem if every driver > is not doing something unique to implement similar functionality) > is worth more than almost exponentially increasing the difficulty of: > - advancing the ecosystem (i.e. it might be easier to understand but > it's way harder to create clean abstractions across such different > hardware). > - driver maintenance (i.e. there will be a constant stream of > regressions hitting your driver as a result of other people working on > their drivers) > - general development (i.e. bug fixes/new features being held back > because they break some other driver) > > Some of those can certainly be titled one way or the other, e.g. the > driver maintenance con be somewhat eased by requiring that every > driver working on top of the new abstraction has to have a stable > Mesa-CI setup (be it lava or ci-tron, or whatever) but all of those > things need to be reasoned about. In my experience abstractions never > have uniform support because some
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
On Thu, Jan 25, 2024 at 8:57 AM Jose Fonseca wrote: > > So far, we've been trying to build those components in terms of the > Vulkan API itself with calls jumping back into the dispatch table to try > and get inside the driver. This is working but it's getting more and more > fragile the more tools we add to that box. A lot of what I want to do with > gallium2 or whatever we're calling it is to fix our layering problems so > that calls go in one direction and we can untangle the jumble. I'm still > not sure what I want that to look like but I think I want it to look a lot > like Vulkan, just with a handier interface. > > That resonates with my experience. For example, Galllium draw module does > some of this too -- it provides its own internal interfaces for drivers, > but it also loops back into Gallium top interface to set FS and rasterizer > state -- and that has *always* been a source of grief. Having control > flow proceeding through layers in one direction only seems an important > principle to observe. It's fine if the lower interface is the same > interface (e.g., Gallium to Gallium, or Vulkan to Vulkan as you allude), > but they shouldn't be the same exact entry-points/modules (ie, no > reentrancy/recursion.) > > It's also worth considering that Vulkan extensibility could come in hand > too in what you want to achieve. For example, Mesa Vulkan drivers could > have their own VK_MESA_internal_ extensions that could be used by the > shared Vulkan code to do lower level things. > We already do that for a handful of things. The fact that Vulkan doesn't ever check the stuff in the pNext chain is really useful for that. 😅 ~Faith > Jose > > > On Wed, Jan 24, 2024 at 3:26 PM Faith Ekstrand > wrote: > >> Jose, >> >> Thanks for your thoughts! >> >> On Wed, Jan 24, 2024 at 4:30 AM Jose Fonseca >> wrote: >> > >> > I don't know much about the current Vulkan driver internals to have or >> provide an informed opinion on the path forward, but I'd like to share my >> backwards looking perspective. >> > >> > Looking back, Gallium was two things effectively: >> > (1) an abstraction layer, that's watertight (as in upper layers >> shouldn't reach through to lower layers) >> > (2) an ecosystem of reusable components (draw, util, tgsi, etc.) >> > >> > (1) was of course important -- and the discipline it imposed is what >> enabled to great simplifications -- but it also became a straight-jacket, >> as GPUs didn't stand still, and sooner or later the >> see-every-hardware-as-the-same lenses stop reflecting reality. >> > >> > If I had to pick one, I'd say that (2) is far more useful and >> practical.Take components like gallium's draw and other util modules. A >> driver can choose to use them or not. One could fork them within Mesa >> source tree, and only the drivers that opt-in into the fork would need to >> be tested/adapted/etc >> > >> > On the flip side, Vulkan API is already a pretty low level HW >> abstraction. It's also very flexible and extensible, so it's hard to >> provide a watertight abstraction underneath it without either taking the >> lowest common denominator, or having lots of optional bits of functionality >> governed by a myriad of caps like you alluded to. >> >> There is a third thing that isn't really recognized in your description: >> >> (3) A common "language" to talk about GPUs and data structures that >> represent that language >> >> This is precisely what the Vulkan runtime today doesn't have. Classic >> meta sucked because we were trying to implement GL in GL. u_blitter, >> on the other hand, is pretty fantastic because Gallium provides a much >> more sane interface to write those common components in terms of. >> >> So far, we've been trying to build those components in terms of the >> Vulkan API itself with calls jumping back into the dispatch table to >> try and get inside the driver. This is working but it's getting more >> and more fragile the more tools we add to that box. A lot of what I >> want to do with gallium2 or whatever we're calling it is to fix our >> layering problems so that calls go in one direction and we can >> untangle the jumble. I'm still not sure what I want that to look like >> but I think I want it to look a lot like Vulkan, just with a handier >> interface. >> >> ~Faith >> >> > Not sure how useful this is in practice to you, but the lesson from my >> POV is
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
On Thu, Jan 25, 2024 at 5:06 PM Gert Wollny wrote: > Hi, > > thanks, Faith, for bringing this discussion up. > > I think with Venus we are more interested in using utility libraries on > an as-needed basis. Here, most of the time the Vulkan commands are just > serialized according to the Venus protocol and this is then passed to > the host because usually it wouldn't make sense to let the guest > translate the Vulkan commands to something different (e.g. something > that is commonly used in a runtime), only to then re-encode this in the > Venus driver to satisfy the host Vulkan driver - just think Spir-V: > why would we want to have NIR only to then re-encode it to Spir-V? > I think Venus is an entirely different class of driver. It's not even really a driver. It's more of a Vulkan layer that has a VM boundary in the middle. It's attempting to be as thin of a Vulkan -> Vulkan pass-through as possible. As such, it doesn't use most of the shared stuff anyway. It uses the dispatch framework and that's really about it. As long as that code stays in-tree roughly as-is, I think Venus will be fine. > I'd also like to give a +1 to the points raised by Triang3l and others > about the potential of breaking other drivers. I've certainly be bitten > by this on the Gallium side with r600, and unfortunately I can't set up > a CI in my home office (and after watching the XDC talk about setting > up your own CI I was even more discouraged to do this). > That's a risk with all common code. You could raise the same risk with NIR or basically anything else. Sure, if someone wants to go write all the code themselves in an attempt to avoid bugs, I guess they're free to do that. I don't really see that as a compelling argument, though. Also, while you experienced gallium breakage with r600, having worked on i965, I can guarantee you that that's still better than maintaining a classic (non-gallium) GL driver. 🙃 At the moment, given the responses I've seen and the scope of the project as things are starting to congeal in my head, I don't think this will be an incremental thing where drivers get converted as we go anymore. If we really do want to flip the flow, I think it'll be invasive enough that we'll build gallium2 and then people can port to it if they want. I may port a driver or two myself but those will be things I own or am at least willing to deal with the bug fallout for. Others can port or not at-will. This is what I meant when I said elsewhere that we're probably heading towards a gallium/classic situation again. I don't expect anyone to port until the benefits outweigh the costs but I do expect the benefits will be there eventually. ~Faith
Re: Queries regarding the Khronos specification license
What do you mean "re-implementing parts of the Vulkan APIs"? I have a feeling someone is confused about licensing Also, I'm NOT a lawyer. What follows does not constitute legal advice and anyone who's actually concerned about the legal implications should consult an actual lawyer who is familiar with international copyright law. Okay, with that said, I don't think anyone in the OpenBSD world has anything to worry about. The only thing being distributed under Apache 2.0 are the Vulkan headers, not any of the driver code implementing Vulkan. If someone is that worried about the license of a handful of headers, I think they should just go through the OpenBSD approval process and get them approved. I guess you'll have to also get the loader approved but I doubt there's any real problems there, either. A for Khronos copyright. Yes, we should be good there. Most Vulkan drivers in Mesa are conformant implementations and therefore it's fine to use the Vulkan trademark in association with them. If you're talking about making a different spec that looks like Vulkan and uses different names for everything just to avoid the Apache 2.0 license, don't do that. That will get you in trouble with Khronos and I will NAK any attempt to do that in Mesa. Again, I'm not a lawyer. ~Faith On Tue, Feb 6, 2024 at 11:52 AM Paianis wrote: > Hi all, > > For context, I'm interested in re-implementing parts of the Vulkan APIs > (at least the parts necessary to develop a Wayland compositor), as the > OpenBSD project won't accept Apache License 2.0 for code except when it > is deemed unavoidable (LLVM), and the Khronos' APIs use this license. > > The Khronos specifications for Vulkan and later OpenGL versions use this > license: > > > https://www.khronos.org/legal/Khronos_Specification_Copyright_License_Header > > Have Mesa3D developers had to use the specifications under > registry.khronos.org for other Khronos standards, and if so, has written > permission to use them and Khronos trademarks ever been sought? > > If I've understood correctly, Mesa3D currently has Vulkan drivers for > some GPUs in various stages of progress, but not a re-implementation of > the Vulkan APIs. Would it be an acceptable home for this (under the MIT > License), or should such a project be separate for now? > > Thanks > > Paianis >
Re: time for amber2 branch?
On Thu, Jun 20, 2024 at 12:30 PM Adam Jackson wrote: > On Thu, Jun 20, 2024 at 10:20 AM Erik Faye-Lund < > erik.faye-l...@collabora.com> wrote: > >> When we did Amber, we had a lot better reason to do so than "these >> drivers cause pain when doing big tree updates". The maintenance burden >> imposed by the drivers proposed for removal here is much, much smaller, >> and doesn't really let us massively clean up things in a way comparable >> to last time. >> > > Yeah, amber was primarily about mothballing src/mesa/drivers/ in my > opinion. It happened to correlate well with the GL 1.x vs 2.0 generational > divide, but that was largely because we had slowly migrated all the GL2 > hardware to gallium drivers (iris and crocus and i915g and r300g were a lot > of work, let's do remember), so the remaining "classic" drivers were only > the best choice for fixed function hardware. Nice bright line in the sand, > there, between the register bank of an overgrown SGI Indy as your state > vector, and the threat of a Turing-complete shader engine. > > I have a harder time finding that line in the sand today. ES3? Compute > shaders? Vulkan 1.0? I'm not sure any of these so fundamentally change the > device programming model, or the baseline API assumptions, that we would > benefit by requiring it of the hardware. I'm happy to be wrong about that! > We're using compute shaders internally in more and more ways, for example, > maybe being able to assume them would be a win. If there's a better design > to be had past some feature level, then by all means let's have that > discussion. > > But if the issue is we don't like how many drivers there are then I am > sorry but at some level that is simply the dimension of the problem. Mesa's > breadth of hardware coverage is at the core of its success. You'd be > hard-pressed to find a GLES1 part anymore, but there are brand-new systems > with Mali-400 MP GPUs, and there's no reason the world's finest GLES2 > implementation should stop working there. > Same. I kinda think the next major cut will be when we go Vulkan-only and leave Zink and a bunch of legacy drivers in a GL branch. That's probably not going to happen for another 5 years at least. ~Faith
Re: Question about BITSET_WORD
I've actually benchmarked this and 32bit is still faster on many modern CPUs. Also, I would be very surprised if we could change it without breaking the universe. I'm sure there are hard-coded 32s various places. ~Faith On Wed, Aug 21, 2024 at 8:13 AM Christophe JAILLET < christophe.jail...@wanadoo.fr> wrote: > Hi, > > I'm new to this list, so sorry if it is not the correct place. > > I've started to looked at the source code of mesa and I wonder why in > src/util/bitset.h we have: > > #define BITSET_WORD unsigned int > > This is as-is since at least 2015, probably 2011. > > Would it make sense to have it as a long, at least on 64 bits arch? > (the linux kernel uses bitmaps as unsigned long) > > I don't think that it should be a noticeable speed-up, but at least on > Linux it could save some cycles when doing some OR or AND and co on > bitmaps on a 64 bits cpu. > > Just my 2c. > > Christophe JAILLET >
Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
The timing here isn't great, unfortunately. I'd love to contribute more to the discussion but I'm going on leave starting next week until mid-Febuary so I won't be able to participate much until then. I'll try to leave a few thoughts, though. On Fri, Oct 18, 2024 at 5:10 PM Derek Lesho wrote: > Hey everyone 👋, > > I'm Derek from the Wine project, and wanted to start a discussion with > y'all about potentially extending the Mesa OGL drivers to help us with a > functionality gap we're facing. > > Problem Space: > > In the last few years Wine's support for running 32-bit windows apps in > a 64-bit host environment (wow64) has almost reached feature completion, > but there remains a pain point with OpenGL applications: Namely that > Wine can't return a 64-bit GL implementation's buffer mappings to a 32 > bit application when the address is outside of the 32-bit range. > > Currently, we have a workaround that will copy any changes to the > mapping back to the host upon glBufferUnmap, but this of course is slow > when the implementation directly returns mapped memory, and doesn't work > for GL_PERSISTENT_BIT, where directly mapped memory is required. > > A few years ago we also faced this problem with Vulkan's, which was > solved through the VK_EXT_map_memory_placed extension Faith drafted, > allowing us to use our Wine-internal allocator to provide the pages the > driver maps to. I'm now wondering if an GL equivalent would also be seen > as feasible amongst the devs here. > > Proposed solution: > > As the GL backend handles host mapping in its own code, only giving > suballocations from its mappings back to the App, the problem is a > little bit less straight forward in comparison to our Vulkan solution: > If we just allowed the application to set its own placed mapping when > calling glMapBuffer, the driver might then have to handle moving buffers > out of already mapped ranges, and would lose control over its own memory > management schemes. > > Therefore, I propose a GL extension that allows the GL client to provide > a mapping and unmapping callback to the implementation, to be used > whenever the driver needs to perform such operations. This way the > driver remains in full control of its memory management affairs, and the > amount of work for an implementation as well as potential for bugs is > kept minimal. I've written a draft implementation in Zink using > map_memory_placed [1] and a corresponding Wine MR utilizing it [2], and > would be curious to hear your thoughts. I don't have experience in the > Mesa codebase, so I apologize if the branch is a tad messy. > It's an interesting approach, to be sure. I don't mean that as a bad or good thing as I haven't given this enough thought with GL in mind to have a better, more well thought out plan. The most obvious issue that jumps out to me is that we really want that callback to be set before anyone ever maps a buffer that might possibly get exposed to the client and we want it to never change. If this were Vulkan, we'd have you provide it at vkCreateDevice() time. But this is GL where everybody loves a big mutable state object. If we do go with callbacks (and it's still not 100% clear to me what the right choice is), we'd want them to be somehow set-once and set before any buffers are created. I'm not 100% sure how you'd spec that or how we'd enforce it. There may be some precedent for this somewhere in GL (no_error, maybe?) but I'm not sure. The other question that comes to mind is when exactly we'd be expected to use these things. Obviously, we need to do so for any map that may be exposed to the client. However, it's not always easy to do that because you don't know at buffer create time whether or not it will be persistently mapped. A driver is likely to have all sorts of internal mappings for things and, while those can come from one of those ranges, it'll burn more of that precious 32-bit address space than needed. This gets worse when you take sub-allocation into account. If we're okay with all buffer mappings going down the client-request path then it's probably okay. The driver just might need an extra bit in its buffer cache key. I'm also sitting here trying to come up with some plan that would let us do this more like Vulkan and I'm having trouble coming up with one that works. GL has no concept of "create time". We could theoretically do something where we flush everything, copy the data to a new placed-mappable buffer and then continue on but that's gonna suck. I think that's all that comes to mind immediately. As I said at the top, I'm happy to talk more in a few months. Best of luck until then! ~Faith > In theory, the only requirement from drivers from the extension would be > that glMapBuffer always return a pointer from within a page allocated > through the provided callbacks, so that it can be guaranteed to be > positioned within the required address space. Wine would then use it's > existing workaround for other types o
Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment
On January 14, 2025 03:39:45 Marek Olšák wrote:
I would keep the existing modifier interfaces, API extensions, and
expectations the same as today for simplicity.
The new linear modifier definition (proposal) will have these fields:
5 bits for log2 pitch alignment in bytes
5 bits for log2 height alignment in rows
5 bits for log2 offset alignment in bytes
5 bits for log2 minimum pitch in bytes
5 bits for log2 minimum (2D) image size in bytes
I'm not strictly opposed to adding a new modifier or two but this seems
massively over-designed. First off, no one uses anything but simple 2D
images for WSI and BOs are allocated in units of 4k pages so 2, 4, and 5
can go. If we assume pitch alignment and offset alignment are the same (and
offset is almost always 0 anyway), 3 can go.
Even with that, I'm struggling to see how useful this is. My understanding
is that you're trying to solve a problem where you need an exact 64-byte
alignment for some AMD scanout stuff. That's not even possible to support
on Nvidia (minimum alignment is 128B) so practically you're looking at one
modifier that's shared between AMD and Intel. Why can't we just add an AMD
modifier, make Intel support it, and move on?
Otherwise we're massively exploding the modifier space for... Why? Intel
will have to advertise basically all of them. Nvidia will advertise most of
them. AMD will advertise something. And now apps have tens of thousands of
modifiers to sort through when we could have just added one and solved the
problem.
~Faith
The pitch and the image size in bytes are no longer arbitrary values. They
are fixed values computed from {width, height, bpp, modifier} as follows:
aligned_width = align(width * bpp / 8, 1 << log2_pitch_alignment);
aligned_height = align(height, 1 << log2_height_alignment);
pitch = max(1 << log2_minimum_pitch, aligned_width);
image_size = max(1 << log2_minimum_image_size, pitch * aligned_height);
The modifier defines the layout exactly and non-ambiguously. Overaligning
the pitch or height is not supported. Only the offset alignment has some
freedom regarding placement. Drivers can expose whatever they want within
that definition, even exposing only 1 linear modifier is OK. Then, you can
look at modifiers of other drivers if you want to find commonalities.
DRM_FORMAT_MOD_LINEAR needs to go because it prevents apps from detecting
whether 2 devices have 0 compatible memory layouts, which is a useful thing
to know.
Marek
On Fri, Jan 10, 2025 at 4:23 PM James Jones wrote:
On 12/19/24 10:03, Simona Vetter wrote:
On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
For that reason I think linear modifiers with explicit pitch/size
alignment constraints is a sound concept and fits into how modifiers work
overall.
Could we make it (more) clear that pitch alignment is a "special"
constraint (in that it's really a description of the buffer layout),
and that constraints in-general shouldn't be exposed via modifiers?
It's still worryingly common to see requirements for contiguous
allocation, if for no other reason than we'll all be stuck with
Freescale/NXP i.MX6 for a long time to come. Would that be in scope
for expressing constraints via modifiers as well, and if so, should we
be trying to use feature bits to express this?
How this would be used in practice is also way too underdocumented. We
need to document that exact-round-up 64b is more restrictive than
any-multiple-of 64b is more restrictive than 'classic' linear. We need
to document what people should advertise - if we were starting from
scratch, the clear answer would be that anything which doesn't care
should advertise all three, anything advertising any-multiple-of
should also advertise exact-round-up, etc.
But we're not starting from scratch, and since linear is 'special',
userspace already has explicit knowledge of it. So AMD is going to
have to advertise LINEAR forever, because media frameworks know about
DRM_FORMAT_MOD_LINEAR and pass that around explicitly when they know
that the buffer is linear. That and not breaking older userspace
running in containers or as part of a bisect or whatever.
There's also the question of what e.g. gbm_bo_get_modifier() should
return. Again, if we were starting from scratch, most restrictive
would make sense. But we're not, so I think it has to return LINEAR
for maximum compatibility (because modifiers can't be morphed into
other ones for fun), which further cements that we're not removing
LINEAR.
And how should allocators determine what to go for? Given that, I
think the only sensible semantics are, when only LINEAR has been
passed, to pick the most restrictive set possible; when LINEAR
variants have been passed as well as LINEAR, to act as if LINEAR were
not passed at all.
Yeah I think this makes sense, and we'd need to add th
Re: Cannot fork mesa
We've had a lot of spam in the past so new accounts get limited by default. File a support ticket and someone will get to it. But also, the admin team is slammed this week with the GitLab migration so have a little patience. Ping again next week if you haven't heard anything yet. Normally, things are pretty quick but, again, they're in the process of moving to a new cloud provider so things are really busy right now. ~Faith On March 19, 2025 11:34:00 Maciej Dziuban wrote: Hello I just created an account on mesa Gitlab and wanted to make some contributions. However, I cannot fork the project, it says I have reached the projects limit in personal space. It also says I should contact my GitLab administrator. I've been looking for any support contact for a while, but couldn't find it. I'd be grateful for any tips. Regards, Maciej
Re: GL framebuffer fetch behavior
NVIDIA is a texelFetch, so (x, 0, 0, 1) Intel is a TexelFetch pre-SKL. I'm not sure what it is for SKL+. Probably (x, 0, 0, 1) but it's been a while. ~Faith On Wed, Apr 23, 2025 at 1:11 PM Marek Olšák wrote: > AMD lowers it to an image load, which follows the rules for image views, > so (x, 0, 0, 1) for R8_UNORM. > > Marek > > On Wed, Apr 23, 2025 at 12:25 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > >> Hi, >> >> An issue recently came up in the GL working group: what is the robustness >> behavior of framebuffer fetch? For example, if a framebuffer attachment >> format is R8_UNORM, what are the YZW components which get read back? >> >> If people from all the drivers (besides panfrost) which support this >> extension could reply with the expected behavior on their hardware, that >> would be helpful. >> >> >> Thanks, >> Mike >> >
Re: [ANNOUNCE] mesa 25.0.0
Quick correction: PanVK does not have Vulkan 1.4 support. It advertises a 1.4 instance but the actual physical device is still stuck at 1.1. ~Faith On Wed, Feb 19, 2025 at 10:20 AM Eric Engestrom wrote: > Hello everyone, > > I'm happy to announce a new feature release, 25.0.0! > > The flashiest addition is probably the support for Vulkan 1.4 by Anv > (Intel), > Asahi (Apple), Lavapipe (software), NVK (NVIDIA), PanVK (Mali), RADV (AMD), > and Turnip (Qualcomm). > > Users can expect the usual flurry of improvements across all drivers and > components, including these new extensions & features highlighted by > their developers: > - cl_khr_depth_images in rusticl > - Vulkan 1.4 on radv/gfx8+ > - VK_KHR_dedicated_allocation on panvk > - VK_KHR_global_priority on panvk > - VK_KHR_index_type_uint8 on panvk > - VK_KHR_map_memory2 on panvk > - VK_KHR_multiview on panvk/v10+ > - VK_KHR_shader_non_semantic_info on panvk > - VK_KHR_shader_relaxed_extended_instruction on panvk > - VK_KHR_vertex_attribute_divisor on panvk > - VK_KHR_zero_initialize_workgroup_memory on panvk > - VK_KHR_shader_draw_parameters on panvk > - VK_KHR_shader_float16_int8 on panvk > - VK_KHR_8bit_storage on panvk > - VK_EXT__formats on panvk > - VK_EXT_global_priority on panvk > - VK_EXT_global_priority_query on panvk > - VK_EXT_host_query_reset on panvk > - VK_EXT_image_robustness on panvk > - VK_EXT_pipeline_robustness on panvk > - VK_EXT_provoking_vertex on panvk > - VK_EXT_queue_family_foreign on panvk > - VK_EXT_sampler_filter_minmax on panvk > - VK_EXT_scalar_block_layout on panvk > - VK_EXT_tooling_info on panvk > - depthClamp on panvk > - depthBiasClamp on panvk > - drawIndirectFirstInstance on panvk > - fragmentStoresAndAtomics on panvk/v10+ > - sampleRateShading on panvk > - occlusionQueryPrecise on panvk > - shaderInt16 on panvk > - shaderInt64 on panvk > - imageCubeArray on panvk > - VK_KHR_depth_clamp_zero_one on RADV > - VK_KHR_maintenance8 on radv > - VK_KHR_shader_subgroup_rotate on panvk/v10+ > - Vulkan 1.1 on panvk/v10+ > - VK_EXT_subgroup_size_control on panvk/v10+ > - initial GFX12 (RDNA4) support on RADV > > If you find any issues, please report them here: > https://gitlab.freedesktop.org/mesa/mesa/-/issues/new > > The next bugfix release is due in two weeks, on March 5th. > > Cheers, > Eric > > --- > > Danylo Piliaiev (2): > tu: Get correct src view when storing gmem attachment > tu: Handle mismatched mutability when resolving from GMEM > > David Rosca (2): > radv/video: Fix setting balanced preset for HEVC encode with SAO > enabled > radv/video: Move IB header from begin/end to encode_video > > Eric Engestrom (11): > .pick_status.json: Update to e41438275e005bbb20fc9c8115d7d29343c292d8 > ci: debian-testing-ubsan is used by tests > ci/yaml-toml-shell-py-test: don't run on post-merge pipelines > ci/yaml-toml-shell-py-test: run on direct push pipelines > .pick_status.json: Update to a9b6a54a8cce0aab44c81ea4821ee564b939ea51 > .pick_status.json: Update to 06d8afff640c66e51517bf4bebd2a58abb2fa055 > .pick_status.json: Update to 2361ed27f34774f0a73324915a9ddb57f43e112a > .pick_status.json: Update to 56aac9fdecad0f7d335f82653832927486f07d44 > .pick_status.json: Update to 6b20b0658489afe745a28b8f09c57067e45b47f3 > docs: add release notes for 25.0.0 > VERSION: bump for 25.0.0 > > Eric R. Smith (2): > panfrost: fix YUV center information for 422 > panfrost: fix backward propagation of values in loops > > Erik Faye-Lund (1): > panvk: report passing the VK CTS > > Faith Ekstrand (11): > nvk: Rename nvk_descriptor_set::mapped_ptr > nvk: Respect VK_DESCRIPTOR_POOL_CREATE_HOST_ONLY_BIT_EXT > nvk: Implement descriptorBufferPushDescriptors > nvk: Pull shaders from the state command buffer in > nvk_cmd_process_cmds() > nvk: Handle shader==NULL in nvk_cmd_upload_qmd() > nvk: Allow sparse loads on EDB buffers > nak: Handle sparse texops with unused color destinations > nvk: Use suld for EDB uniform texel buffers > nvk: Align UBO/SSBO addresses down rather than up > nak: Use suld.constant when ACCESS_CAN_REORDER is set > nvk: Use suld.constant for EDB uniform texel buffers > > Georg Lehmann (2): > nir: fix range analysis for frcp > nir: fix frsq range analysis > > Konstantin Seurer (1): > gallivm: Remove loop limiting > > Lionel Landwerlin (2): > anv: disable VF statistics for memcpy > anv: ensure Wa_16012775297 interacts correctly with Wa_18020335297 > > Lorenzo Rossi
Re: Cannot fork mesa
File an issue here: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues On Wed, Mar 19, 2025 at 12:10 PM Maciej Dziuban wrote: > That's what I was suspecting. The site is still a little unstable. It's > fine, I can wait. As I mentioned, I can't find a way to contact the admins > on gitlab.freedesktop.org. How do I file a suport ticket? > > On Wed, Mar 19, 2025, 18:00 Faith Ekstrand wrote: > >> We've had a lot of spam in the past so new accounts get limited by >> default. File a support ticket and someone will get to it. >> >> But also, the admin team is slammed this week with the GitLab migration >> so have a little patience. Ping again next week if you haven't heard >> anything yet. Normally, things are pretty quick but, again, they're in the >> process of moving to a new cloud provider so things are really busy right >> now. >> >> ~Faith >> >> On March 19, 2025 11:34:00 Maciej Dziuban >> wrote: >> >>> Hello >>> >>> I just created an account on mesa Gitlab and wanted to make some >>> contributions. >>> >>> However, I cannot fork the project, it says I have reached the projects >>> limit in personal space. It also says I should contact my GitLab >>> administrator. I've been looking for any support contact for a while, but >>> couldn't find it. >>> >>> I'd be grateful for any tips. >>> >>> Regards, >>> Maciej >>> >> >>
Re: The CS has been rejected (-2)
Please file a bug at https://gitlab.freedesktop.org/mesa/mesa/-/issues rather than sending an e-mail. It's much easier for the developers to track it that way. ~Faith On Thu, May 29, 2025 at 2:53 PM Jean-François Boyer wrote: > I have a setup with linux kernel 6.12 mesa3d 24.0.9 llvm 15.0.3 running > on a AMD board > OpenGL Vendor: AMD > OpenGL Renderer: AMD Ryzen Embedded V1807B with Radeon Vega Gfx (radeonsi, > raven, LLVM 15.0.3, DRM 3.61, 6.12.19) > OpenGL Version: 4.6 (Core Profile) Mesa 24.0.9 > > I am having issues when running a game. I got this error amdgpu: The CS > has been rejected (-2) in dmesg and the game stopped. > > The graphical stack seems to be working fine since I am able to run > glmark2 without issue. > > I strace the game and found this iotctl call crashing > > `3185 ioctl(58, DRM_IOCTL_AMDGPU_CS, 0x7f0767af7ae0) = -1 ENOENT (No such > file or directory)` > `3185 write(2, "amdgpu: The CS has been rejected (-2).\n", 39) = 39` > > This same game was working properly with kernel 5.10 and mesa3d 21.1.1 > > any help or fix would be appreciated > > thank you > Jee >
