Re: Moving code around, post classic
On Tuesday, December 7, 2021 12:26:29 PM PST Emma Anholt wrote: > On Mon, Dec 6, 2021 at 3:50 PM Dylan Baker wrote: > > > > Classic is gone, and the cleanups have begun, obviously. There is > > another cleanup that I had in mind, which is moving src/mesa into > > src/gallium/frontends/mesa. This makes the build system a little > > cleaner, as currently we do some bending over backwards to get gallium, > > mesa, and their tests built in the right order. But that's a big ol `git > > mv`, and when I proposed it Dave and Ilia suggested it would be best to > > do all of the post-classic code motion at once. So, let's talk about > > what we want to move, and where we want to move it. > > > > Among the suggestions we had were: > > > > 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for > >this) > > > >Seems like a pretty obvoius thing to do, given that all of the other > >gallium state trackers live there (OpenCL, video, d3d9, etc) > > > > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > > > Given that there are now no? drivers that use GLSL-IR directly, it > > might make sense to move the glsl compiler into the mesa > > state_tracker, and just have that lower to TGSI or NIR, and treat > > GLSL-IR as an implementation detail of the OpenGL frontend. > > > > Unfortunately, there are a lot of code outside of glsl that uses the > > linked list implementation in the glsl compiler, and not the on in > > util. > > > > 3. Move src/gallium* to src/ > > > > This was suggested, though given the existance of Vulkan, it wasn't > > clear that this was a good idea or not > > > > 4. What to do about the src/loader, src/glx, src/egl, src/mapi, > >src/glapi > > > > These are all part of OpenGL, but not really part of gallium, but if > > we don't move src/gallium/* to src/ does it make sense to leave them > > in the root? > > FWIW, I'm mildly against moving src/mesa to src/gallium/frontends/mesa > (or /gl would make more sense to me at that point). That feels like a > whole lot of gratuitous typing of longer paths to me, when GL feels > like a pretty fundamental thing in the repo and not worth hiding way > down there. I'm also against moving src/mesa for the reasons that Dave and Emma mention. I'm not really a huge fan of any of the proposed mass-moves. Moving files around can really be quite painful. I'm still occasionally digging through history for files moved from src/mesa/drivers/dri/i965 to src/intel/compiler, and having to take extra steps there. Which is fine, because there was a very good reason for that move (we introduced a Vulkan driver, and the compiler moved to be a shared component). If we wanted to move src/loader, src/glx, src/egl, we could potentially make those src/mesa/wsi/{egl,glx,loader}. And maybe src/mesa/mapi. But really, it seems like the benefit there is "less directories in src" which I don't think is really worth it. --Ken signature.asc Description: This is a digitally signed message part.
Re: Moving code around, post classic
On Thu, Dec 9, 2021 at 11:24 AM Timur Kristóf wrote: > On Tue, 2021-12-07 at 08:19 -0500, Alyssa Rosenzweig wrote > > > > If it were just linked lists, I'd say someone should write the > > Coccinelle to transform the tree to use the one in util and call it a > > day. It's a bit more complicated though, NIR depends on GLSL types. > > Though that could probably continue to live in its current location > > even > > if glsl moves? Might breed confusion. > > > These GLSL types seem to be used by a lot more than just GLSL. To avoid > some of the confusion, why not rename them to something like NIR types, > or something along these lines? > First off, they're already in src/compiler, not src/compiler/glsl. Could/should we rename them? I'm fine with that and, honestly, the only reason I haven't yet is because it's a pile of work and because I've not been able to come up with a better name than `glsl_type` that sounds generic to all compiler things. We could go `nir_type`, I guess but that's already kind-of taken by NIR ALU types. Then again, those could be renamed too. I'm kind-of meh on it. --Jason
Re: Moving code around, post classic
On Tue, 2021-12-07 at 08:19 -0500, Alyssa Rosenzweig wrote > > If it were just linked lists, I'd say someone should write the > Coccinelle to transform the tree to use the one in util and call it a > day. It's a bit more complicated though, NIR depends on GLSL types. > Though that could probably continue to live in its current location > even > if glsl moves? Might breed confusion. These GLSL types seem to be used by a lot more than just GLSL. To avoid some of the confusion, why not rename them to something like NIR types, or something along these lines?
Re: Moving code around, post classic
While the current directory structure is confusing, the new suggested directory structure might not be helpful because GL is more spread out anyway. mapi is libglapi, so it seems to be its own thing, not a gallium thing glx is libgl, same thing. egl is libegl, same thing. ... unless we want to merge all libs with all drivers into one mega lib built by gallium. loader is more like util. mapi is partially util too besides being a lib. Marek On Tue, Dec 7, 2021 at 2:45 PM Dave Airlie wrote: > On Tue, 7 Dec 2021 at 09:51, Dylan Baker wrote: > > > > Classic is gone, and the cleanups have begun, obviously. There is > > another cleanup that I had in mind, which is moving src/mesa into > > src/gallium/frontends/mesa. This makes the build system a little > > cleaner, as currently we do some bending over backwards to get gallium, > > mesa, and their tests built in the right order. But that's a big ol `git > > mv`, and when I proposed it Dave and Ilia suggested it would be best to > > do all of the post-classic code motion at once. So, let's talk about > > what we want to move, and where we want to move it. > > > > Among the suggestions we had were: > > > > 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for > >this) > > > >Seems like a pretty obvoius thing to do, given that all of the other > >gallium state trackers live there (OpenCL, video, d3d9, etc) > > I'm against this just for history finding reasons, although git tracks > file renames it AFAIK fails to track directories, so you can only > follow the files not the whole subdir back through history once you > move it. > > But I guess enough people want to see it happen, and it will. > > > > > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > > > Given that there are now no? drivers that use GLSL-IR directly, it > > might make sense to move the glsl compiler into the mesa > > state_tracker, and just have that lower to TGSI or NIR, and treat > > GLSL-IR as an implementation detail of the OpenGL frontend. > > > > Unfortunately, there are a lot of code outside of glsl that uses the > > linked list implementation in the glsl compiler, and not the on in > > util. > > > > 3. Move src/gallium* to src/ > > > > This was suggested, though given the existance of Vulkan, it wasn't > > clear that this was a good idea or not > > > > 4. What to do about the src/loader, src/glx, src/egl, src/mapi, > >src/glapi > > > > These are all part of OpenGL, but not really part of gallium, but if > > we don't move src/gallium/* to src/ does it make sense to leave them > > in the root? > > src/opengl ? > > Dave. >
Re: Moving code around, post classic
On Mon, Dec 6, 2021 at 3:50 PM Dylan Baker wrote: > > Classic is gone, and the cleanups have begun, obviously. There is > another cleanup that I had in mind, which is moving src/mesa into > src/gallium/frontends/mesa. This makes the build system a little > cleaner, as currently we do some bending over backwards to get gallium, > mesa, and their tests built in the right order. But that's a big ol `git > mv`, and when I proposed it Dave and Ilia suggested it would be best to > do all of the post-classic code motion at once. So, let's talk about > what we want to move, and where we want to move it. > > Among the suggestions we had were: > > 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for >this) > >Seems like a pretty obvoius thing to do, given that all of the other >gallium state trackers live there (OpenCL, video, d3d9, etc) > > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > Given that there are now no? drivers that use GLSL-IR directly, it > might make sense to move the glsl compiler into the mesa > state_tracker, and just have that lower to TGSI or NIR, and treat > GLSL-IR as an implementation detail of the OpenGL frontend. > > Unfortunately, there are a lot of code outside of glsl that uses the > linked list implementation in the glsl compiler, and not the on in > util. > > 3. Move src/gallium* to src/ > > This was suggested, though given the existance of Vulkan, it wasn't > clear that this was a good idea or not > > 4. What to do about the src/loader, src/glx, src/egl, src/mapi, >src/glapi > > These are all part of OpenGL, but not really part of gallium, but if > we don't move src/gallium/* to src/ does it make sense to leave them > in the root? FWIW, I'm mildly against moving src/mesa to src/gallium/frontends/mesa (or /gl would make more sense to me at that point). That feels like a whole lot of gratuitous typing of longer paths to me, when GL feels like a pretty fundamental thing in the repo and not worth hiding way down there.
Re: Moving code around, post classic
On Tue, 7 Dec 2021 at 09:51, Dylan Baker wrote: > > Classic is gone, and the cleanups have begun, obviously. There is > another cleanup that I had in mind, which is moving src/mesa into > src/gallium/frontends/mesa. This makes the build system a little > cleaner, as currently we do some bending over backwards to get gallium, > mesa, and their tests built in the right order. But that's a big ol `git > mv`, and when I proposed it Dave and Ilia suggested it would be best to > do all of the post-classic code motion at once. So, let's talk about > what we want to move, and where we want to move it. > > Among the suggestions we had were: > > 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for >this) > >Seems like a pretty obvoius thing to do, given that all of the other >gallium state trackers live there (OpenCL, video, d3d9, etc) I'm against this just for history finding reasons, although git tracks file renames it AFAIK fails to track directories, so you can only follow the files not the whole subdir back through history once you move it. But I guess enough people want to see it happen, and it will. > > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > Given that there are now no? drivers that use GLSL-IR directly, it > might make sense to move the glsl compiler into the mesa > state_tracker, and just have that lower to TGSI or NIR, and treat > GLSL-IR as an implementation detail of the OpenGL frontend. > > Unfortunately, there are a lot of code outside of glsl that uses the > linked list implementation in the glsl compiler, and not the on in > util. > > 3. Move src/gallium* to src/ > > This was suggested, though given the existance of Vulkan, it wasn't > clear that this was a good idea or not > > 4. What to do about the src/loader, src/glx, src/egl, src/mapi, >src/glapi > > These are all part of OpenGL, but not really part of gallium, but if > we don't move src/gallium/* to src/ does it make sense to leave them > in the root? src/opengl ? Dave.
Re: Moving code around, post classic
December 6, 2021 5:51 PM, "Dylan Baker" wrote: > 4. What to do about the src/loader, src/glx, src/egl, src/mapi, > src/glapi > > These are all part of OpenGL, but not really part of gallium, but if > we don't move src/gallium/* to src/ does it make sense to leave them > in the root? > You can lump src/hgl and include/HaikuGL in with these as well. Same general idea as glx on Linux, but under Haiku with C++ These are all technically "OpenGL Dispatch Code" using old-timey Mesa terminology. "dispatch" + "gl" are good verbs for them :-) -- Alex
Re: Moving code around, post classic
On Tue, 2021-12-07 at 08:19 -0500, Alyssa Rosenzweig wrote: > > > > > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > > > Given that there are now no? drivers that use GLSL-IR directly, > > it > > might make sense to move the glsl compiler into the mesa > > state_tracker, and just have that lower to TGSI or NIR, and > > treat > > GLSL-IR as an implementation detail of the OpenGL frontend. > > It would be an ack from, but... > > > Unfortunately, there are a lot of code outside of glsl that > > uses the > > linked list implementation in the glsl compiler, and not the on > > in > > util. > > If it were just linked lists, I'd say someone should write the > Coccinelle to transform the tree to use the one in util and call it a > day. It's a bit more complicated though, NIR depends on GLSL types. > Though that could probably continue to live in its current location > even > if glsl moves? Might breed confusion. I agree moving this is more trouble than its worth IMO, its easy to understand why its in the compiler dir, and its right next to all the common code it shares with nir, shader_info, glsl_types, etc. Its also worth noting that the state tracker isn't the only potental user as the glsl compile can still be build as a standalone executable. My prefrence is for this code to stay where it is.
Re: Moving code around, post classic
> 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for >this) > >Seems like a pretty obvoius thing to do, given that all of the other >gallium state trackers live there (OpenCL, video, d3d9, etc) Ack from me. > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > Given that there are now no? drivers that use GLSL-IR directly, it > might make sense to move the glsl compiler into the mesa > state_tracker, and just have that lower to TGSI or NIR, and treat > GLSL-IR as an implementation detail of the OpenGL frontend. It would be an ack from, but... > Unfortunately, there are a lot of code outside of glsl that uses the > linked list implementation in the glsl compiler, and not the on in > util. If it were just linked lists, I'd say someone should write the Coccinelle to transform the tree to use the one in util and call it a day. It's a bit more complicated though, NIR depends on GLSL types. Though that could probably continue to live in its current location even if glsl moves? Might breed confusion. > 3. Move src/gallium* to src/ > > This was suggested, though given the existance of Vulkan, it wasn't > clear that this was a good idea or not If src/gallium/drivers/* is distributed to src/*/* this becomes a lot less interesting I think?
Re: Moving code around, post classic
>If we're going to do this, I wonder if we don't want to go even further >and get rid of src/gallium/drivers and move the respective folders to >src/vendor.** So, instead of src/gallium/drivers/(iris|crocus), we'd have >src/intel/gallium/iris and src/intel/gallium/crocus or maybe >src/intel/iris and src/intel/crocus. >--Jason If we do that, only one level of indirection -- ie src/intel/(iris|crocus) -- is my preference, because src/panfrost/gallium/panfrost is a silly path. src/panfrost/gallium or (ick) src/panfrost/panfrost saves the extra nesting. Same goes for any vendor with only a single Gallium driver (most of them...?)
Re: Moving code around, post classic
On Mon, Dec 6, 2021 at 5:50 PM Dylan Baker wrote: > Classic is gone, and the cleanups have begun, obviously. There is > another cleanup that I had in mind, which is moving src/mesa into > src/gallium/frontends/mesa. This makes the build system a little > cleaner, as currently we do some bending over backwards to get gallium, > mesa, and their tests built in the right order. But that's a big ol `git > mv`, and when I proposed it Dave and Ilia suggested it would be best to > do all of the post-classic code motion at once. So, let's talk about > what we want to move, and where we want to move it. > > Among the suggestions we had were: > > 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for >this) > >Seems like a pretty obvoius thing to do, given that all of the other >gallium state trackers live there (OpenCL, video, d3d9, etc) > > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > Given that there are now no? drivers that use GLSL-IR directly, it > might make sense to move the glsl compiler into the mesa > state_tracker, and just have that lower to TGSI or NIR, and treat > GLSL-IR as an implementation detail of the OpenGL frontend. > > Unfortunately, there are a lot of code outside of glsl that uses the > linked list implementation in the glsl compiler, and not the on in > util. > +1 to the first two. > 3. Move src/gallium* to src/ > > This was suggested, though given the existance of Vulkan, it wasn't > clear that this was a good idea or not > If we're going to do this, I wonder if we don't want to go even further and get rid of src/gallium/drivers and move the respective folders to src/vendor. So, instead of src/gallium/drivers/(iris|crocus), we'd have src/intel/gallium/iris and src/intel/gallium/crocus or maybe src/intel/iris and src/intel/crocus. --Jason > 4. What to do about the src/loader, src/glx, src/egl, src/mapi, >src/glapi > > These are all part of OpenGL, but not really part of gallium, but if > we don't move src/gallium/* to src/ does it make sense to leave them > in the root? > > > Cheers, > Dylan
Re: Moving code around, post classic
Hi, 1. If this happens, let's call it src/gallium/frontends/gl. 3. The src directory already has too much stuff. Marek On Mon, Dec 6, 2021 at 6:51 PM Dylan Baker wrote: > Classic is gone, and the cleanups have begun, obviously. There is > another cleanup that I had in mind, which is moving src/mesa into > src/gallium/frontends/mesa. This makes the build system a little > cleaner, as currently we do some bending over backwards to get gallium, > mesa, and their tests built in the right order. But that's a big ol `git > mv`, and when I proposed it Dave and Ilia suggested it would be best to > do all of the post-classic code motion at once. So, let's talk about > what we want to move, and where we want to move it. > > Among the suggestions we had were: > > 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for >this) > >Seems like a pretty obvoius thing to do, given that all of the other >gallium state trackers live there (OpenCL, video, d3d9, etc) > > 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well > > Given that there are now no? drivers that use GLSL-IR directly, it > might make sense to move the glsl compiler into the mesa > state_tracker, and just have that lower to TGSI or NIR, and treat > GLSL-IR as an implementation detail of the OpenGL frontend. > > Unfortunately, there are a lot of code outside of glsl that uses the > linked list implementation in the glsl compiler, and not the on in > util. > > 3. Move src/gallium* to src/ > > This was suggested, though given the existance of Vulkan, it wasn't > clear that this was a good idea or not > > 4. What to do about the src/loader, src/glx, src/egl, src/mapi, >src/glapi > > These are all part of OpenGL, but not really part of gallium, but if > we don't move src/gallium/* to src/ does it make sense to leave them > in the root? > > > Cheers, > Dylan
Moving code around, post classic
Classic is gone, and the cleanups have begun, obviously. There is another cleanup that I had in mind, which is moving src/mesa into src/gallium/frontends/mesa. This makes the build system a little cleaner, as currently we do some bending over backwards to get gallium, mesa, and their tests built in the right order. But that's a big ol `git mv`, and when I proposed it Dave and Ilia suggested it would be best to do all of the post-classic code motion at once. So, let's talk about what we want to move, and where we want to move it. Among the suggestions we had were: 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for this) Seems like a pretty obvoius thing to do, given that all of the other gallium state trackers live there (OpenCL, video, d3d9, etc) 2. Move src/compiler/glsl into src/gallium/frontends/mesa as well Given that there are now no? drivers that use GLSL-IR directly, it might make sense to move the glsl compiler into the mesa state_tracker, and just have that lower to TGSI or NIR, and treat GLSL-IR as an implementation detail of the OpenGL frontend. Unfortunately, there are a lot of code outside of glsl that uses the linked list implementation in the glsl compiler, and not the on in util. 3. Move src/gallium* to src/ This was suggested, though given the existance of Vulkan, it wasn't clear that this was a good idea or not 4. What to do about the src/loader, src/glx, src/egl, src/mapi, src/glapi These are all part of OpenGL, but not really part of gallium, but if we don't move src/gallium/* to src/ does it make sense to leave them in the root? Cheers, Dylan signature.asc Description: signature