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
Amber branch plan
Since classic is gone, I thought I'd lay out my thinking for Amber. I'm assuming that we'll branch Amber from the 21.3 branch, after that reaches normal EOL. That gives us the benefit of developing on top of a known good state for classic drivers, and should minimize friction for distros dealing with classic. If anyone wants to backport changes from main to amber they can obviously do so. Are there any objections to that plan? Dylan signature.asc Description: signature
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
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: Amber branch plan
+1 On Mon, Dec 6, 2021 at 5:51 PM Dylan Baker wrote: > Since classic is gone, I thought I'd lay out my thinking for Amber. > > I'm assuming that we'll branch Amber from the 21.3 branch, after that > reaches normal EOL. That gives us the benefit of developing on top of a > known good state for classic drivers, and should minimize friction for > distros dealing with classic. If anyone wants to backport changes from > main to amber they can obviously do so. > > Are there any objections to that plan? > > Dylan
