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...?)
