Re: [Mesa-dev] RFC: Prune stale components
On 3 March 2015 at 12:15, Jose Fonseca jfons...@vmware.com wrote: On 03/03/15 11:59, Emil Velikov wrote: On 3 March 2015 at 09:36, Jose Fonseca jfons...@vmware.com wrote: On 28/02/15 00:24, Rob Clark wrote: On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are So it looks from the replies that rbug and rbug-gui is still useful. If we're going to keep this should we move the rbug-gui tool within the mesa tree ? It would be nice to spare some of the sigh... it does not build and let you guys just use it. +1 It sounds a good idea FWIW. I believe that rbug-gui depends on the gallium interface, and we don't maintain backwards compatibility, so moving it rbug-gui into somewhere like src/gallium/tools/ and have it built by default should enable to keep it in sync more easily. Indeed that was the reason I brought it up. That said, integrating rbug-gui into Mesa tree is beyond my immediate goals/needs. So I'll let those who do use rbug + rbug-gui to take that task on. Ouch... did not mean to come across as you should do it or anything along those lines. No prob. I just want to make sure that, by agreeing, I wasn't volunteering :) I'll need to read up a bit on how to preserve the history, but it's already on my list :-) I tried to do that sort of git-history-rewriting/spliting acrobatics in the past. And I have mixed feelings from my experience: being able to do `git blame` on the new tree is indeed nice, but it's hard to get the history right, in particular it's pretty hard to ensure that things build at arbitrary commits, which can create troubles when bisecting (particularly because there is no option for git bisect --ignore-changes-in-this-path src/gallium/tools/rbug-gui...) The alternative would be to make http://cgit.freedesktop.org/mesa/rbug-gui/ read-only, or just slap a big notice in description/read-me saying this code is unmaintained and moved to XYZ, import rbug-gui as a single commit, and mention which rbu-gui commit this was taken from in the mesa commit message. As a learning exercise I've went ahead with the git filter-branch acrobatics. Afaict things should be perfectly bisect-able as I've intentionally removed the history of configure.ac and Makefile.in. The whole thing seems to build like a charm, but I cannot get it running (something funny is happening between GTK and QT). Can someone give it a try ? The series can be found in branch rbug-gui-import at https://github.com/evelikov/Mesa/. Should I spam the list with the three patches first one of which adds 4000 lines of code ? Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 04/03/15 00:24, Emil Velikov wrote: On 03/03/15 22:04, Jose Fonseca wrote: On 03/03/15 18:39, Emil Velikov wrote: On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote: ... I've prototyped this in https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degld=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZUs=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyoe= The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? I've spotted a few trivial bits: - windows/gdi: Remove. Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST The driver had interesting api/wrapper similar to osmesa. Did not know that :-) - st/egl: Remove. Update the src/egl/main/Sconscript to create a SharedLibrary, add versioning, create symlink - copy the bits from egl-static. Drop st/egl and targets/egl-static from src/gallium/Makefile.am:EXTRA_DIST Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from src/egl/main/Android.mk. - st/vega: Remove. A few openvg references left - one in configure.ac another one in docs/contents.html Thanks. I pushed a new version of the branch with all issues fixed. I'm guessing you made a typo in src/egl/main/SConscript +egl = env.InstallSharedLibrary(egl, version=(1, 0, 0)) Shouldn't the version be 1.4 ? No, it wasn't a typo. It matches what autotools does now. I can't say which is more correct 1.0 or 1.4, but it doesn't make sense for SCons to do something different than autotools for the exact same code. The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. The Android build is mostly limping around mesa 10.4. I've pinged the Android-x86 guys, but but might get to it soon(ish). Don't worry too much about it. I'm guessing that the scons and automake build do not point out anything unusual ? Right. automake, scons/linux and scons/windows all build happily. Of course, automake has many options, and I only tested one (with dri and gallium sw rasterizers). These components are rather nicely isolated, so it should not matter that much. I'm suspecting that scons does not link against all libs for libEGL. ldd -r build/linux-x86_64-debug/egl/main/libEGL.so is clean. Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up, yet feel free to do it as a follow up. I would highly recommend adding it (-Wl...) for every SharedLibrary in scons. Using the version scripts like autotools, to restrict the exported symbols, will be great. I'll see what can be done. Unfortunately (at least in the past) we used to have .so depending on symbols from the .so/executable that dlopened it (ie, cyclic dependencies), so doing this universally woulddn't be possible. Not sure if that's still the case. With the versioning question addressed, feel free to add Reviewed-by: Emil Velikov emil.l.veli...@gmail.com Thanks for the reviews. Please drop a couple of lines in the release notes, when you're finished removing all the old/unused bits. Sure. -Emil P.S. Strange. After spending so much time fixing the builds, it feels so nice as various chunks of it end up removed :-P Yeah. I feel the same, even with code I wrote myself. Maintaining code takes a toll in time and energy (all those worries about things one should have done but never had the time). So removing code (or abandoning projects) is effectively taking a weight from ones conscience. And enables one to use that time/energy for better things. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 4 March 2015 at 08:31, Jose Fonseca jfons...@vmware.com wrote: On 04/03/15 00:24, Emil Velikov wrote: On 03/03/15 22:04, Jose Fonseca wrote: On 03/03/15 18:39, Emil Velikov wrote: On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote: ... I've prototyped this in https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degld=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZUs=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyoe= The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? I've spotted a few trivial bits: - windows/gdi: Remove. Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST The driver had interesting api/wrapper similar to osmesa. Did not know that :-) - st/egl: Remove. Update the src/egl/main/Sconscript to create a SharedLibrary, add versioning, create symlink - copy the bits from egl-static. Drop st/egl and targets/egl-static from src/gallium/Makefile.am:EXTRA_DIST Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from src/egl/main/Android.mk. - st/vega: Remove. A few openvg references left - one in configure.ac another one in docs/contents.html Thanks. I pushed a new version of the branch with all issues fixed. I'm guessing you made a typo in src/egl/main/SConscript +egl = env.InstallSharedLibrary(egl, version=(1, 0, 0)) Shouldn't the version be 1.4 ? No, it wasn't a typo. It matches what autotools does now. I can't say which is more correct 1.0 or 1.4, but it doesn't make sense for SCons to do something different than autotools for the exact same code. Nicely spotted. I've naively assumed that we had 1.4 for Autotools. The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. The Android build is mostly limping around mesa 10.4. I've pinged the Android-x86 guys, but but might get to it soon(ish). Don't worry too much about it. I'm guessing that the scons and automake build do not point out anything unusual ? Right. automake, scons/linux and scons/windows all build happily. Of course, automake has many options, and I only tested one (with dri and gallium sw rasterizers). These components are rather nicely isolated, so it should not matter that much. I'm suspecting that scons does not link against all libs for libEGL. ldd -r build/linux-x86_64-debug/egl/main/libEGL.so is clean. Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up, yet feel free to do it as a follow up. I would highly recommend adding it (-Wl...) for every SharedLibrary in scons. Using the version scripts like autotools, to restrict the exported symbols, will be great. I'll see what can be done. Unfortunately (at least in the past) we used to have .so depending on symbols from the .so/executable that dlopened it (ie, cyclic dependencies), so doing this universally woulddn't be possible. Not sure if that's still the case. The only such case in current mesa ought to be the dri modules (LoadableModule) - both gallium and classic ones. That is for the Autotools build, cannot say anything for scons. Thanks again for clearing these up. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 28/02/15 00:24, Rob Clark wrote: On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are So it looks from the replies that rbug and rbug-gui is still useful. If we're going to keep this should we move the rbug-gui tool within the mesa tree ? It would be nice to spare some of the sigh... it does not build and let you guys just use it. +1 It sounds a good idea FWIW. I believe that rbug-gui depends on the gallium interface, and we don't maintain backwards compatibility, so moving it rbug-gui into somewhere like src/gallium/tools/ and have it built by default should enable to keep it in sync more easily. That said, integrating rbug-gui into Mesa tree is beyond my immediate goals/needs. So I'll let those who do use rbug + rbug-gui to take that task on. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 27/02/15 15:16, Jose Fonseca wrote: As we're gaining momentum cleanup Mesa code, I think it would help if we also removed some stale components. What do people feel about removing: - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I haven't used in a very long time, and given that the old SW rasterizer is so far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard to imagine this will ever be useful again - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems to have dwindled away. I recall Zack himself saying that much. The code would still be interesting if we wanted to implement NV_path_rendering [1], but given the trend of the next gen graphics APIs, it seems unlikely that this becomes ARB or core. - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but since then I discovered WGL/GLX_EXT_create_context_es_profile, and the odds of us (VMware) needing this again are dimmer than last time, so I have to admit it does seem unlikely we or anybody will need it again, and we can always revert it from history.. Anything else? Thanks for all the replies. So in summary, I'll post patches to remove: - src/mesa/drivers/windows/gdi - src/gallium/state_trackers/vega/,src/mapi/vgapi/ - src/gallium/state_trackers/egl/ plus whatever modules get orphaned as result of that I'll try to do one component at a time (in case we want to revert), but if keeping things in a building state ends up being too tricky then I might squash them together. Components that people explicitly showed interest in maintaining (therefore left alone) are: - src/gallium/drivers/rbug/ - src/mesa/drivers/x11/ - src/mesa/drivers/osmesa/ Things that haven't been mentioned but might be considering for a 2nd round are: - src/gallium/drivers/noop Do people use it? - src/gallium/drivers/galahad/ Again, this also tends to get broken. Architecturally it's the right thing to do, but I ended up giving up on enabling it, as it causes crashes. If nobody uses it, might as well face reality here. As I said, layered drivers are nice conceptually, but there are serious challenges with them in practice: - the gallium interface is always changing, so they do get broken easily, particularly when they are not frequently used (ie, enabled by default) - some state trackers have private interfaces with pipe drivers, making it impossible to use layered drivers. In other words, we have to make a good analysis which layered drivers are or not worth maintaining, and make a effort to keep those that are deem to be useful in running condition. Because keeping them around half-heartedly is the worse outcome: time is spent maintaining them, but they are never good enough to be useful/trusted... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 03/03/15 12:31, Jose Fonseca wrote: On 27/02/15 15:16, Jose Fonseca wrote: As we're gaining momentum cleanup Mesa code, I think it would help if we also removed some stale components. What do people feel about removing: - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I haven't used in a very long time, and given that the old SW rasterizer is so far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard to imagine this will ever be useful again - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems to have dwindled away. I recall Zack himself saying that much. The code would still be interesting if we wanted to implement NV_path_rendering [1], but given the trend of the next gen graphics APIs, it seems unlikely that this becomes ARB or core. - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but since then I discovered WGL/GLX_EXT_create_context_es_profile, and the odds of us (VMware) needing this again are dimmer than last time, so I have to admit it does seem unlikely we or anybody will need it again, and we can always revert it from history.. Anything else? Thanks for all the replies. So in summary, I'll post patches to remove: - src/mesa/drivers/windows/gdi - src/gallium/state_trackers/vega/,src/mapi/vgapi/ - src/gallium/state_trackers/egl/ plus whatever modules get orphaned as result of that I've prototyped this in http://cgit.freedesktop.org/~jrfonseca/mesa/log/?h=remove-st-egl The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote: ... I've prototyped this in http://cgit.freedesktop.org/~jrfonseca/mesa/log/?h=remove-st-egl The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? I've spotted a few trivial bits: - windows/gdi: Remove. Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST The driver had interesting api/wrapper similar to osmesa. Did not know that :-) - st/egl: Remove. Update the src/egl/main/Sconscript to create a SharedLibrary, add versioning, create symlink - copy the bits from egl-static. Drop st/egl and targets/egl-static from src/gallium/Makefile.am:EXTRA_DIST Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from src/egl/main/Android.mk. - st/vega: Remove. A few openvg references left - one in configure.ac another one in docs/contents.html The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. The Android build is mostly limping around mesa 10.4. I've pinged the Android-x86 guys, but but might get to it soon(ish). Don't worry too much about it. I'm guessing that the scons and automake build do not point out anything unusual ? Thanks Jose. Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 03/03/15 18:39, Emil Velikov wrote: On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote: ... I've prototyped this in https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degld=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZUs=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyoe= The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? I've spotted a few trivial bits: - windows/gdi: Remove. Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST The driver had interesting api/wrapper similar to osmesa. Did not know that :-) - st/egl: Remove. Update the src/egl/main/Sconscript to create a SharedLibrary, add versioning, create symlink - copy the bits from egl-static. Drop st/egl and targets/egl-static from src/gallium/Makefile.am:EXTRA_DIST Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from src/egl/main/Android.mk. - st/vega: Remove. A few openvg references left - one in configure.ac another one in docs/contents.html Thanks. I pushed a new version of the branch with all issues fixed. The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. The Android build is mostly limping around mesa 10.4. I've pinged the Android-x86 guys, but but might get to it soon(ish). Don't worry too much about it. I'm guessing that the scons and automake build do not point out anything unusual ? Right. automake, scons/linux and scons/windows all build happily. Of course, automake has many options, and I only tested one (with dri and gallium sw rasterizers). Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 03/03/15 22:04, Jose Fonseca wrote: On 03/03/15 18:39, Emil Velikov wrote: On 3 March 2015 at 17:16, Jose Fonseca jfons...@vmware.com wrote: ... I've prototyped this in https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degld=AwIBaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZUs=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyoe= The changes are massive, so I'm not sure it's even worth spamming the list with them. Could you please give a look and let me know if there are any concerns? I've spotted a few trivial bits: - windows/gdi: Remove. Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST The driver had interesting api/wrapper similar to osmesa. Did not know that :-) - st/egl: Remove. Update the src/egl/main/Sconscript to create a SharedLibrary, add versioning, create symlink - copy the bits from egl-static. Drop st/egl and targets/egl-static from src/gallium/Makefile.am:EXTRA_DIST Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from src/egl/main/Android.mk. - st/vega: Remove. A few openvg references left - one in configure.ac another one in docs/contents.html Thanks. I pushed a new version of the branch with all issues fixed. I'm guessing you made a typo in src/egl/main/SConscript +egl = env.InstallSharedLibrary(egl, version=(1, 0, 0)) Shouldn't the version be 1.4 ? The only snafu is Android.mk -- it will be broken with gallium drivers until somebody familiar with that infrastructure updates it to use egl_dri2. But it should build fine without gallium drivers. The Android build is mostly limping around mesa 10.4. I've pinged the Android-x86 guys, but but might get to it soon(ish). Don't worry too much about it. I'm guessing that the scons and automake build do not point out anything unusual ? Right. automake, scons/linux and scons/windows all build happily. Of course, automake has many options, and I only tested one (with dri and gallium sw rasterizers). These components are rather nicely isolated, so it should not matter that much. I'm suspecting that scons does not link against all libs for libEGL. Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up, yet feel free to do it as a follow up. I would highly recommend adding it (-Wl...) for every SharedLibrary in scons. Using the version scripts like autotools, to restrict the exported symbols, will be great. With the versioning question addressed, feel free to add Reviewed-by: Emil Velikov emil.l.veli...@gmail.com Please drop a couple of lines in the release notes, when you're finished removing all the old/unused bits. -Emil P.S. Strange. After spending so much time fixing the builds, it feels so nice as various chunks of it end up removed :-P ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 03/03/15 11:59, Emil Velikov wrote: On 3 March 2015 at 09:36, Jose Fonseca jfons...@vmware.com wrote: On 28/02/15 00:24, Rob Clark wrote: On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are So it looks from the replies that rbug and rbug-gui is still useful. If we're going to keep this should we move the rbug-gui tool within the mesa tree ? It would be nice to spare some of the sigh... it does not build and let you guys just use it. +1 It sounds a good idea FWIW. I believe that rbug-gui depends on the gallium interface, and we don't maintain backwards compatibility, so moving it rbug-gui into somewhere like src/gallium/tools/ and have it built by default should enable to keep it in sync more easily. Indeed that was the reason I brought it up. That said, integrating rbug-gui into Mesa tree is beyond my immediate goals/needs. So I'll let those who do use rbug + rbug-gui to take that task on. Ouch... did not mean to come across as you should do it or anything along those lines. No prob. I just want to make sure that, by agreeing, I wasn't volunteering :) I'll need to read up a bit on how to preserve the history, but it's already on my list :-) I tried to do that sort of git-history-rewriting/spliting acrobatics in the past. And I have mixed feelings from my experience: being able to do `git blame` on the new tree is indeed nice, but it's hard to get the history right, in particular it's pretty hard to ensure that things build at arbitrary commits, which can create troubles when bisecting (particularly because there is no option for git bisect --ignore-changes-in-this-path src/gallium/tools/rbug-gui...) The alternative would be to make http://cgit.freedesktop.org/mesa/rbug-gui/ read-only, or just slap a big notice in description/read-me saying this code is unmaintained and moved to XYZ, import rbug-gui as a single commit, and mention which rbu-gui commit this was taken from in the mesa commit message. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 3 March 2015 at 09:36, Jose Fonseca jfons...@vmware.com wrote: On 28/02/15 00:24, Rob Clark wrote: On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are So it looks from the replies that rbug and rbug-gui is still useful. If we're going to keep this should we move the rbug-gui tool within the mesa tree ? It would be nice to spare some of the sigh... it does not build and let you guys just use it. +1 It sounds a good idea FWIW. I believe that rbug-gui depends on the gallium interface, and we don't maintain backwards compatibility, so moving it rbug-gui into somewhere like src/gallium/tools/ and have it built by default should enable to keep it in sync more easily. Indeed that was the reason I brought it up. That said, integrating rbug-gui into Mesa tree is beyond my immediate goals/needs. So I'll let those who do use rbug + rbug-gui to take that task on. Ouch... did not mean to come across as you should do it or anything along those lines. I'll need to read up a bit on how to preserve the history, but it's already on my list :-) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
Please keep drivers/noop. It's useful sometimes and it's very easy to maintain. Marek On Tue, Mar 3, 2015 at 1:31 PM, Jose Fonseca jfons...@vmware.com wrote: On 27/02/15 15:16, Jose Fonseca wrote: As we're gaining momentum cleanup Mesa code, I think it would help if we also removed some stale components. What do people feel about removing: - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I haven't used in a very long time, and given that the old SW rasterizer is so far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard to imagine this will ever be useful again - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems to have dwindled away. I recall Zack himself saying that much. The code would still be interesting if we wanted to implement NV_path_rendering [1], but given the trend of the next gen graphics APIs, it seems unlikely that this becomes ARB or core. - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but since then I discovered WGL/GLX_EXT_create_context_es_profile, and the odds of us (VMware) needing this again are dimmer than last time, so I have to admit it does seem unlikely we or anybody will need it again, and we can always revert it from history.. Anything else? Thanks for all the replies. So in summary, I'll post patches to remove: - src/mesa/drivers/windows/gdi - src/gallium/state_trackers/vega/,src/mapi/vgapi/ - src/gallium/state_trackers/egl/ plus whatever modules get orphaned as result of that I'll try to do one component at a time (in case we want to revert), but if keeping things in a building state ends up being too tricky then I might squash them together. Components that people explicitly showed interest in maintaining (therefore left alone) are: - src/gallium/drivers/rbug/ - src/mesa/drivers/x11/ - src/mesa/drivers/osmesa/ Things that haven't been mentioned but might be considering for a 2nd round are: - src/gallium/drivers/noop Do people use it? - src/gallium/drivers/galahad/ Again, this also tends to get broken. Architecturally it's the right thing to do, but I ended up giving up on enabling it, as it causes crashes. If nobody uses it, might as well face reality here. As I said, layered drivers are nice conceptually, but there are serious challenges with them in practice: - the gallium interface is always changing, so they do get broken easily, particularly when they are not frequently used (ie, enabled by default) - some state trackers have private interfaces with pipe drivers, making it impossible to use layered drivers. In other words, we have to make a good analysis which layered drivers are or not worth maintaining, and make a effort to keep those that are deem to be useful in running condition. Because keeping them around half-heartedly is the worse outcome: time is spent maintaining them, but they are never good enough to be useful/trusted... Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca jfons...@vmware.com wrote: Anything else? Are the classic xlib and osmesa drivers useful given that they both have Gallium alternatives these days? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca jfons...@vmware.com wrote: - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are Another vote for keeping rbug.. Maybe some extensions to expose things like tgsi level shaders and maybe some other gallium level state to apitrace could replace part of what I use rbug for. Although the single-stepping is useful too.. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 02/27/2015 10:05 AM, Matt Turner wrote: On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca jfons...@vmware.com wrote: Anything else? Are the classic xlib and osmesa drivers useful given that they both have Gallium alternatives these days? Yeah, I'd like to keep those. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 02/27/2015 07:16 AM, Jose Fonseca wrote: As we're gaining momentum cleanup Mesa code, I think it would help if we also removed some stale components. What do people feel about removing: - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I haven't used in a very long time, and given that the old SW rasterizer is so far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard to imagine this will ever be useful again I'm in favor. - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems to have dwindled away. I recall Zack himself saying that much. The code would still be interesting if we wanted to implement NV_path_rendering [1], but given the trend of the next gen graphics APIs, it seems unlikely that this becomes ARB or core. I'm not a big fan of NV_path_rendering, and it would surprise me greatly if it ever became a core part of OpenGL... or even an ARB extension. Either way, if we delete the code, it is still in GIT. - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but since then I discovered WGL/GLX_EXT_create_context_es_profile, and the odds of us (VMware) needing this again are dimmer than last time, so I have to admit it does seem unlikely we or anybody will need it again, and we can always revert it from history.. Anything else? Jose [1] http://zrusin.blogspot.co.uk/2011/09/nv-path-rendering.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On Fri, Feb 27, 2015 at 4:16 PM, Jose Fonseca jfons...@vmware.com wrote: As we're gaining momentum cleanup Mesa code, I think it would help if we also removed some stale components. What do people feel about removing: - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I haven't used in a very long time, and given that the old SW rasterizer is so far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard to imagine this will ever be useful again - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are I used it to debug Unigine Sanctuary last year and it helped me track down a driver bug. It works pretty well. It has some cool features like being able to watch textures and renderbuffers as they change in real time. I guess whoever wants to use it should expect that some functions may not be implemented. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca jfons...@vmware.com wrote: - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are FWIW I tried to use it when debugging a VDPAU issue, but getting it to pass through video textures (even without any inspection) proved harder than (eventually) fixing the driver bug. I think it's especially useful for situations where apitrace doesn't work, and even where it does, it can provide visibility into intermediate stages of rendering. I think it's a useful-enough tool to keep around. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 02/27/2015 08:16 AM, Jose Fonseca wrote: As we're gaining momentum cleanup Mesa code, I think it would help if we also removed some stale components. What do people feel about removing: - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I haven't used in a very long time, and given that the old SW rasterizer is so far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard to imagine this will ever be useful again Sounds good. - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are Either way is OK by me. - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems to have dwindled away. I recall Zack himself saying that much. The code would still be interesting if we wanted to implement NV_path_rendering [1], but given the trend of the next gen graphics APIs, it seems unlikely that this becomes ARB or core. If Zack's OK with it, fine by me. Though it's a little sad it hasn't been used more. - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but since then I discovered WGL/GLX_EXT_create_context_es_profile, and the odds of us (VMware) needing this again are dimmer than last time, so I have to admit it does seem unlikely we or anybody will need it again, and we can always revert it from history.. The fact this stuff can be revived from git if actually needed makes it a fairly easy decision, I think. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On 27/02/15 15:16, Jose Fonseca wrote: As we're gaining momentum cleanup Mesa code, I think it would help if we also removed some stale components. What do people feel about removing: - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I haven't used in a very long time, and given that the old SW rasterizer is so far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard to imagine this will ever be useful again - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are If we're going to keep this should we move the rbug-gui tool within the mesa tree ? It would be nice to spare some of the sigh... it does not build and let you guys just use it. - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems to have dwindled away. I recall Zack himself saying that much. The code would still be interesting if we wanted to implement NV_path_rendering [1], but given the trend of the next gen graphics APIs, it seems unlikely that this becomes ARB or core. - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but since then I discovered WGL/GLX_EXT_create_context_es_profile, and the odds of us (VMware) needing this again are dimmer than last time, so I have to admit it does seem unlikely we or anybody will need it again, and we can always revert it from history.. Anything else? Some of the winsys/sw are used by the st/egl alone. Their nukeage will also allow us to simplify the pipe-loader business, and hide/push some of the mayhem from the state-trackers into that aux module :) All that fill follow up afterwords of course. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Prune stale components
On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: - src/gallium/drivers/rbug: -- do people use it? does it work? it predates apitrace GL + GUI, which sort of enables a lot of the same things, but without the issue of having to hit moving target, which is what gallium interfaces are If we're going to keep this should we move the rbug-gui tool within the mesa tree ? It would be nice to spare some of the sigh... it does not build and let you guys just use it. +1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
