Hey there, while seeing the new submit request (https://build.opensuse.org/request/show/197847) and with it the loss of the comments to the previous submit request (hidden in that request), here now a message to all involved (and interested) people.
Johannes, personally i'd really like to have your changes in Mesa but sumski and i, we had some concerns noted in the comments of the previous SR (maybe you want to look at them):
- Do you think this is stable enough for 13.1? (or at least a broader audience not willing to test bleeding edge software) - Will this go into Mesa mainline soon? Anytime? It's quite a deviation from upstream. - Why did you remove several packages? - Split the huge patch for easier overview.
PS: Hopefully i did understand your comment right sumski ;)
Thanks, Tobias
Am Samstag, 7. September 2013, 20:15:30 schrieb Tobias Klausmann:
Hey there, while seeing the new submit request (https://build.opensuse.org/request/show/197847) and with it the loss of the comments to the previous submit request (hidden in that request), here now a message to all involved (and interested) people.
Johannes, personally i'd really like to have your changes in Mesa but sumski and i, we had some concerns noted in the comments of the previous SR (maybe you want to look at them):
- Do you think this is stable enough for 13.1? (or at least a broader
audience not willing to test bleeding edge software)
See below. But yes it is stable. Even more it should fix some upstream issues like EGL runtime error: https://bugs.freedesktop.org/show_bug.cgi?id=64810
Also Ubuntu builds e. g. libgallium and libmesagallium shared but not with this buildtime speedup shown in my patches: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/mesa/saucy/view/he... http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/mesa/saucy/view/he...
- Will this go into Mesa mainline soon? Anytime? It's quite a deviation
from upstream.
Sorry for German: Damit ich mich nicht immer über die unnötigen Diskussionen, das Bitten und Betteln sowie der einhergehenden Ignoranz der Upstream-Entwickler - selbst bei Patches zur Behebung trivialer Kompilierfehler - ärgern muss, habe ich Einspielrechte beantragt: https://bugs.freedesktop.org/show_bug.cgi?id=69053
I want to maintain master-shared and 9.2-shared branches there until upstream come up to accept them ...
- Why did you remove several packages?
See below (unneccesary).
- Split the huge patch for easier overview.
https://github.com/jobermayr/mesa/commits/9.2
or for mesa master:
https://github.com/jobermayr/mesa/commits/master
PS: Hopefully i did understand your comment right sumski ;)
Thanks, Tobias
Am Samstag, 7. September 2013, 19:05:11 schrieb Johannes Obermayr:
New SR: https://build.opensuse.org/request/show/197847
- Drop u_mesa-glapi_dispatch.patch
It is now possible to use $(VISIBILITY_CFLAGS) also for glsl: https://build.opensuse.org/package/rdiff/home:jobermayr:branches:X11:XOrg/Me... So only required symbols are visible from now on :)
Btw. You can see how difficult it is to get even agreed patches upstreamed: http://lists.freedesktop.org/archives/mesa-dev/2013-September/044341.html
Am Donnerstag, 5. September 2013, 15:41:30 schrieb Johannes Obermayr:
Am Donnerstag, 5. September 2013, 14:25:05 schrieb Stefan Dirsch:
Hi Johannes
I'm afraid we need to discuss these changes. Adding Egbert and Michal.
Comments see below.
On Tue, Sep 03, 2013 at 09:11:45PM +0000, johannesobermayr@gmx.de wrote:
home:jobermayr:branches:X11:XOrg/Mesa -> X11:XOrg/Mesa
https://build.opensuse.org/request/show/197345
Description: See Mesa.changes
changes files:
--- Mesa.changes +++ Mesa.changes @@ -1,0 +2,23 @@ +Tue Sep 3 21:02:55 UTC 2013 - johannesobermayr@gmx.de
+- Drop 0011_u_Fix-crash-in-swrast-when-setting-a-texture-for.patch
It's no longer applicable, which does not necessarily mean, that the issue has been resolved.
That's right. But I could see it has been disabled for ~ 1 1/2 years: https://build.opensuse.org/package/rdiff/X11:XOrg/Mesa?linkrev=base&rev=...
+- Drop 0017_u_mesa-9.0-i965-Make-sure-we-do-render-between.patch
I do not see how this git commit is related to the patch. Could you elaborate?
Discussion with the author in #dri-devel: [Sonntag, 1. September 2013] [15:39:34] <jobermayr> marcheu: Is this patch obsolete: https://build.opensuse.org/package/view_file/X11:XOrg/Mesa/u_mesa-9.0-i965-M... [Sonntag, 1. September 2013] [20:53:51] <marcheu> jobermayr: yup anholt fixed it in git mesa [Sonntag, 1. September 2013] [22:10:24] <jobermayr> marcheu: That means it is still required in 9.2 branch? [Sonntag, 1. September 2013] [22:13:51] <marcheu> I don't think so, check for anholt's commit about URB [Sonntag, 1. September 2013] [22:17:39] <marcheu> http://cgit.freedesktop.org/mesa/mesa/commit/?id=1dfea559c3f188a7a82a4abc097... [Sonntag, 1. September 2013] [22:18:53] <jobermayr> Thanks.
+------------------------------------------------------------------- +Sat Aug 31 18:00:20 UTC 2013 - johannesobermayr@gmx.de
+- Drop IndirectGL/osmesa
- Use --enable-osmesa instead
ok
- Remove Mesa-libIndirectGL0 and Mesa-libIndirectGL-devel packages
Why? We needed this lib in the past. Unfortunately I no longer can remember, for which purposes and which software components. compiz or some related lib maybe? Anyway, theoretically it should also be possible to use the regular libGL with indirect rendering and software rendering though by setting
LIBGL_ALWAYS_INDIRECT/LIBGL_ALWAYS_SOFTWARE
environment variables.
--> http://tirdc.livejournal.com/24963.html
So, from my side I would like to accept these changes.
- Speed up build
Sure, that's true.
+- Use patchset from https://github.com/jobermayr/mesa/commits/9.2
- Add 0018_u_build_shared.tar.bz2
- Build as much shared as possible to remove duplicates in binaries
- Less memory consumption at runtime
Please push this patch uptream. Otherwise we cannot accept. Last time we tried to share code in DRI drivers we failed miserably (undefined symbols)! BTW, this is a patch, not a tarball (of patches). ;-)
I am working with Andreas Boll (aboll) from Intel to upstream it. But my experience is same as always: maintainers first welcome to do things, then when I try to upstream well tested work they don't push - even more: they show intolerable! and don't reply ... :-(
Don't think about undefined symbols. I set for each shared lib "-Wl,--no-undefined": https://github.com/jobermayr/mesa/commit/cd04198 or commented what TODO
You can also see in this patchset fixes for a lot of undefined symbols ... Because of my stupidness I even had to make all symbols in glsl visible to fix two of them: https://github.com/jobermayr/mesa/commit/bf17997
This is well tested on a AMD Fusion (r600), Nvidia ION (nouveau) and ATI Mobility Radeon (r200).
To say it like our last minister of defence: "[...] in mühevollster Kleinstarbeit [...]" :)
- Remove Mesa-libglapi0 and Mesa-libglapi-devel packages
Why? Is this the consequence of your patch to share as much code as possible?
Because Mesa's internal libs are now in %_libdir/mesa-9.2.0/* or %_libdir/mesa-9.3.0-devel/* which belongs to Mesa package ...
Please don't split Mesa package more. Because of the dependencies IMHO there should even be only Mesa and Mesa-devel package ...
- Speed up build
+- Prefix numbers to patches
If really helpful/required, we want it the other way round, i.e. u_XXXX_...
I am trying to make Adam Jackson (ajax) to upstream 0013 and 0015 ;)
<snip>
Following changes since SR 197847:
+ Drop drirc and use upstream instead http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/common/drirc
+ Only install libvdpau_*.so.1 and libXvMC*.so libs needed by dlopen wrappers https://github.com/jobermayr/mesa/commit/18472db
+ A follow-up to "Install all internal shared libs to $(libdir)/mesa-$VERSION." https://github.com/jobermayr/mesa/commit/811e4fa
+ Apply pending adaption of XShmGetImage patch (bnc#807205,rh#917687) https://bugzilla.redhat.com/attachment.cgi?id=732422 + Readd lost part in 16bpp patch Please read comments I added for them ...
Am Samstag, 7. September 2013, 21:28:31 schrieb Johannes Obermayr:
Am Samstag, 7. September 2013, 20:15:30 schrieb Tobias Klausmann:
Hey there, while seeing the new submit request (https://build.opensuse.org/request/show/197847) and with it the loss of the comments to the previous submit request (hidden in that request), here now a message to all involved (and interested) people.
Johannes, personally i'd really like to have your changes in Mesa but sumski and i, we had some concerns noted in the comments of the previous SR (maybe you want to look at them):
- Do you think this is stable enough for 13.1? (or at least a broader
audience not willing to test bleeding edge software)
See below. But yes it is stable. Even more it should fix some upstream issues like EGL runtime error: https://bugs.freedesktop.org/show_bug.cgi?id=64810
Also Ubuntu builds e. g. libgallium and libmesagallium shared but not with this buildtime speedup shown in my patches: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/mesa/saucy/view/he... http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/mesa/saucy/view/he...
- Will this go into Mesa mainline soon? Anytime? It's quite a deviation
from upstream.
Sorry for German: Damit ich mich nicht immer über die unnötigen Diskussionen, das Bitten und Betteln sowie der einhergehenden Ignoranz der Upstream-Entwickler - selbst bei Patches zur Behebung trivialer Kompilierfehler - ärgern muss, habe ich Einspielrechte beantragt: https://bugs.freedesktop.org/show_bug.cgi?id=69053
I want to maintain master-shared and 9.2-shared branches there until upstream come up to accept them ...
- Why did you remove several packages?
See below (unneccesary).
- Split the huge patch for easier overview.
https://github.com/jobermayr/mesa/commits/9.2
or for mesa master:
https://github.com/jobermayr/mesa/commits/master
PS: Hopefully i did understand your comment right sumski ;)
Thanks, Tobias
Am Samstag, 7. September 2013, 19:05:11 schrieb Johannes Obermayr:
New SR: https://build.opensuse.org/request/show/197847
- Drop u_mesa-glapi_dispatch.patch
It is now possible to use $(VISIBILITY_CFLAGS) also for glsl: https://build.opensuse.org/package/rdiff/home:jobermayr:branches:X11:XOrg/Me... So only required symbols are visible from now on :)
Btw. You can see how difficult it is to get even agreed patches upstreamed: http://lists.freedesktop.org/archives/mesa-dev/2013-September/044341.html
Am Donnerstag, 5. September 2013, 15:41:30 schrieb Johannes Obermayr:
Am Donnerstag, 5. September 2013, 14:25:05 schrieb Stefan Dirsch:
Hi Johannes
I'm afraid we need to discuss these changes. Adding Egbert and Michal.
Comments see below.
On Tue, Sep 03, 2013 at 09:11:45PM +0000, johannesobermayr@gmx.de wrote:
home:jobermayr:branches:X11:XOrg/Mesa -> X11:XOrg/Mesa
https://build.opensuse.org/request/show/197345
Description: See Mesa.changes
changes files:
--- Mesa.changes +++ Mesa.changes @@ -1,0 +2,23 @@ +Tue Sep 3 21:02:55 UTC 2013 - johannesobermayr@gmx.de
+- Drop 0011_u_Fix-crash-in-swrast-when-setting-a-texture-for.patch
It's no longer applicable, which does not necessarily mean, that the issue has been resolved.
That's right. But I could see it has been disabled for ~ 1 1/2 years: https://build.opensuse.org/package/rdiff/X11:XOrg/Mesa?linkrev=base&rev=...
+- Drop 0017_u_mesa-9.0-i965-Make-sure-we-do-render-between.patch
I do not see how this git commit is related to the patch. Could you elaborate?
Discussion with the author in #dri-devel: [Sonntag, 1. September 2013] [15:39:34] <jobermayr> marcheu: Is this patch obsolete: https://build.opensuse.org/package/view_file/X11:XOrg/Mesa/u_mesa-9.0-i965-M... [Sonntag, 1. September 2013] [20:53:51] <marcheu> jobermayr: yup anholt fixed it in git mesa [Sonntag, 1. September 2013] [22:10:24] <jobermayr> marcheu: That means it is still required in 9.2 branch? [Sonntag, 1. September 2013] [22:13:51] <marcheu> I don't think so, check for anholt's commit about URB [Sonntag, 1. September 2013] [22:17:39] <marcheu> http://cgit.freedesktop.org/mesa/mesa/commit/?id=1dfea559c3f188a7a82a4abc097... [Sonntag, 1. September 2013] [22:18:53] <jobermayr> Thanks.
+------------------------------------------------------------------- +Sat Aug 31 18:00:20 UTC 2013 - johannesobermayr@gmx.de
+- Drop IndirectGL/osmesa
- Use --enable-osmesa instead
ok
- Remove Mesa-libIndirectGL0 and Mesa-libIndirectGL-devel packages
Why? We needed this lib in the past. Unfortunately I no longer can remember, for which purposes and which software components. compiz or some related lib maybe? Anyway, theoretically it should also be possible to use the regular libGL with indirect rendering and software rendering though by setting
LIBGL_ALWAYS_INDIRECT/LIBGL_ALWAYS_SOFTWARE
environment variables.
--> http://tirdc.livejournal.com/24963.html
So, from my side I would like to accept these changes.
- Speed up build
Sure, that's true.
+- Use patchset from https://github.com/jobermayr/mesa/commits/9.2
- Add 0018_u_build_shared.tar.bz2
- Build as much shared as possible to remove duplicates in binaries
- Less memory consumption at runtime
Please push this patch uptream. Otherwise we cannot accept. Last time we tried to share code in DRI drivers we failed miserably (undefined symbols)! BTW, this is a patch, not a tarball (of patches). ;-)
I am working with Andreas Boll (aboll) from Intel to upstream it. But my experience is same as always: maintainers first welcome to do things, then when I try to upstream well tested work they don't push - even more: they show intolerable! and don't reply ... :-(
Don't think about undefined symbols. I set for each shared lib "-Wl,--no-undefined": https://github.com/jobermayr/mesa/commit/cd04198 or commented what TODO
You can also see in this patchset fixes for a lot of undefined symbols ... Because of my stupidness I even had to make all symbols in glsl visible to fix two of them: https://github.com/jobermayr/mesa/commit/bf17997
This is well tested on a AMD Fusion (r600), Nvidia ION (nouveau) and ATI Mobility Radeon (r200).
To say it like our last minister of defence: "[...] in mühevollster Kleinstarbeit [...]" :)
- Remove Mesa-libglapi0 and Mesa-libglapi-devel packages
Why? Is this the consequence of your patch to share as much code as possible?
Because Mesa's internal libs are now in %_libdir/mesa-9.2.0/* or %_libdir/mesa-9.3.0-devel/* which belongs to Mesa package ...
Please don't split Mesa package more. Because of the dependencies IMHO there should even be only Mesa and Mesa-devel package ...
- Speed up build
+- Prefix numbers to patches
If really helpful/required, we want it the other way round, i.e. u_XXXX_...
I am trying to make Adam Jackson (ajax) to upstream 0013 and 0015 ;)
<snip>
On 09.09.2013 03:33, Johannes Obermayr wrote:
Following changes since SR 197847:
- Drop drirc and use upstream instead http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/common/drirc
I'm all for it! Don't know what Stefan says about it!
(snip the rest)
But the rest i can't vote for, at least for now! We are late in the release cycle, so lets take baby steps. Maybe: 1) Drop the patches 2) Drop drirc 3) Remove the packages (after the 13.1 split?) 4) Upstream the shared work (as Stefan stated, that it will not get accepted for now)
Don't waste your time with a big SR nobody is willing to accept, so preserve your work with that.
PS: Stefan maybe you can drop a short note about the drirc file?
Thanks, Tobias
On Mon, Sep 09, 2013 at 03:49:45PM +0200, Tobias Klausmann wrote:
On 09.09.2013 03:33, Johannes Obermayr wrote:
Following changes since SR 197847:
- Drop drirc and use upstream instead http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/common/drirc
I'm all for it! Don't know what Stefan says about it!
(snip the rest)
But the rest i can't vote for, at least for now! We are late in the release cycle, so lets take baby steps. Maybe:
- Drop the patches
- Drop drirc
- Remove the packages (after the 13.1 split?)
- Upstream the shared work (as Stefan stated, that it will not get
accepted for now)
Don't waste your time with a big SR nobody is willing to accept, so preserve your work with that.
PS: Stefan maybe you can drop a short note about the drirc file?
Yes, switching to upstream drirc makes sense for me. It's some time ago I introduced and changed drirc.
Fri Jan 9 19:00:00 CET 2009 - sndirsch@suse.de
- /etc/drirc * disable vblank_mode/force_s3tc_enable and enable disable_lowimpact_fallback for r300 driver to fix performance issues with GoogleEarth and OpenOffice.Org (bnc #438666)
------------------------------------------------------------------- Mon Nov 17 18:35:37 CET 2008 - sndirsch@suse.de
- added global /etc/drirc to disable VBlank for i915 DRI driver (bnc #432980)
And, yes. Baby steps is the right thing to do!
Thanks, Stefan
Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany -------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) --------------------------------------------------------------
Do you guys actually read what I am writing and referring to or do you only see a big SR and patch?
Again the key fixes and improvements: - bnc#833714 (OSMesa symbols) - bnc#807205,rh#917687 (issue with already applied patch) - Readd lost things to the follow-up patch, possibly lost due to merge conflicts - Drop obsolete patches which could mess up things - fdo#64810 (EGL runtime issue), could be also bnc#839074 - ~ 1/2 build time - ~ 1/5 - 1/6 binaries and -debuginfo
Is the only reason you don't want them fixed in 13.1 because they require 22 patches and upstream core devs don't want to talk to me anymore. Maybe they change their mind if one of the big distribution ships them ...
IMHO esp. maintainers should read comments and add a note to each proposed change why it won't be accepted.
Am Montag, 9. September 2013, 16:04:22 schrieb Stefan Dirsch:
On Mon, Sep 09, 2013 at 03:49:45PM +0200, Tobias Klausmann wrote:
On 09.09.2013 03:33, Johannes Obermayr wrote:
Following changes since SR 197847:
- Drop drirc and use upstream instead http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/common/drirc
I'm all for it! Don't know what Stefan says about it!
(snip the rest)
But the rest i can't vote for, at least for now! We are late in the release cycle, so lets take baby steps. Maybe:
- Drop the patches
- Drop drirc
- Remove the packages (after the 13.1 split?)
- Upstream the shared work (as Stefan stated, that it will not get
accepted for now)
Don't waste your time with a big SR nobody is willing to accept, so preserve your work with that.
PS: Stefan maybe you can drop a short note about the drirc file?
Yes, switching to upstream drirc makes sense for me. It's some time ago I introduced and changed drirc.
Fri Jan 9 19:00:00 CET 2009 - sndirsch@suse.de
- /etc/drirc
- disable vblank_mode/force_s3tc_enable and enable disable_lowimpact_fallback for r300 driver to fix performance issues with GoogleEarth and OpenOffice.Org (bnc #438666)
Mon Nov 17 18:35:37 CET 2008 - sndirsch@suse.de
- added global /etc/drirc to disable VBlank for i915 DRI driver (bnc #432980)
And, yes. Baby steps is the right thing to do!
Thanks, Stefan
Public Key available
Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 09.09.2013 16:32, Johannes Obermayr wrote:
Do you guys actually read what I am writing and referring to or do you only see a big SR and patch?
No, at least i did read your emails and looked at the links.
Again the key fixes and improvements:
- bnc#833714 (OSMesa symbols)
- bnc#807205,rh#917687 (issue with already applied patch)
- Readd lost things to the follow-up patch, possibly lost due to merge conflicts
- Drop obsolete patches which could mess up things
- fdo#64810 (EGL runtime issue), could be also bnc#839074
- ~ 1/2 build time
- ~ 1/5 - 1/6 binaries and -debuginfo
If this gets upstreamed we'll take it with pleasure. At least i will ;-). Can't speak for anybody else of course.
Is the only reason you don't want them fixed in 13.1 because...
The reason i can imagine is: Do you know if something breaks? No, you can't. And breaking a key package that late in the release cycle is not a good idea. Maybe it would not break something, but it's really risky. And even after that, who will take care of these changes? If upstream changes something. You? Yes maybe for Mesa 10/11. But what if you lose interest? Can we go back to upstream or do we introduce a problem for later releases.
...they require 22 patches and upstream core devs don't want to talk to me anymore.
If they don't speak to you anymore, sorry. I don't know what happened, so i will not comment on this.
Maybe they change their mind if one of the big distribution ships them ...
You think? If they haven't taken the changes yet, for reason i don't know, they will not get convinced by downstream changes.
IMHO esp. maintainers should read comments and add a note to each proposed change why it won't be accepted.
Sorry to be a little harsh!
Thanks, Tobias
On Monday 09 of September 2013 16:32:52 Johannes Obermayr wrote:
Do you guys actually read what I am writing and referring to or do you only see a big SR and patch?
Again the key fixes and improvements:
First, that kind of mention in changelog would be a big step towards accepting it IMO, since reviewing a 4MB patch with almost only argumenting "builds faster!" is not easy, and one is much closer to decline such SR.
- bnc#833714 (OSMesa symbols)
ok
- bnc#807205,rh#917687 (issue with already applied patch)
- Readd lost things to the follow-up patch, possibly lost due to merge
conflicts - Drop obsolete patches which could mess up things
ok, but i guess it would be good to test "does it mess up things" (also one of reasons why this is a bit hard to get in so late in the game.
- fdo#64810 (EGL runtime issue), could be also bnc#839074
Can't reproduce, and isn't bnc#839074
- ~ 1/2 build time
- ~ 1/5 - 1/6 binaries and -debuginfo
Always good ;-)
Is the only reason you don't want them fixed in 13.1 because they require 22 patches and upstream core devs don't want to talk to me anymore. Maybe they change their mind if one of the big distribution ships them ...
Maybe, but i'm not fond of openSUSE being testing ground for random, huge, not-upstream-ed/-eable patches...
Am Dienstag, 10. September 2013, 00:18:08 schrieb šumski:
On Monday 09 of September 2013 16:32:52 Johannes Obermayr wrote:
Do you guys actually read what I am writing and referring to or do you only see a big SR and patch?
Again the key fixes and improvements:
First, that kind of mention in changelog would be a big step towards accepting it IMO, since reviewing a 4MB patch with almost only argumenting "builds faster!" is not easy, and one is much closer to decline such SR.
Maybe the attached main diff is easier to review.
All other is just moving nv30, nv50 and nvc0 to nouveau subdir (~ 4.5 MB) and adding PUBLIC as well as the required .h file to define Mesa's "visibility" macro.
All required symbols (and additional LIBADDs) were tested in hundreds of "make" and common configure switches ...
As said before changing "-no-undefined" to "-Wl,--no-undefined" shows which symbols are missed. That are a lot in upstream Mesa and I am surprised that it works ATM ...
IMHO it is not a functionality change but a restructuring of code and split into more libraries to speed up build and save space.
I am using it heavily on nouveau, r200 and r600. So I doubt there will be any regressions in functionality (except a negligible more time to dlopen). If but this won't be neccessary, reverting in RC1 would be possible.
- bnc#833714 (OSMesa symbols)
ok
- bnc#807205,rh#917687 (issue with already applied patch)
- Readd lost things to the follow-up patch, possibly lost due to merge
conflicts - Drop obsolete patches which could mess up things
ok, but i guess it would be good to test "does it mess up things" (also one of reasons why this is a bit hard to get in so late in the game.
"get in so late in the game" is not acceptable. Patches must be reviewed on every major package update (last was on Tue Aug 27 23:56:19 UTC 2013). This required review happens now and here.
I am voting to ...
- enable only: Patch16: u_gallium-egl-gbm-use-wayland-cflags.patch Patch18: u_wayland-egl-pc-require-wayland.patch
- remove obsolete patches: Patch11: u_Fix-crash-in-swrast-when-setting-a-texture-for-a-pix.patch Patch14: u_mesa-glapi_dispatch.patch Patch17: u_mesa-9.0-i965-Make-sure-we-do-render-between-two-hiz-flushes.patch
- let reworked in OBS but disable for now (patch author doesn't trust them ATM): Patch13: u_mesa-8.0.1-fix-16bpp.patch Patch15: u_mesa-8.0-llvmpipe-shmget.patch
- fdo#64810 (EGL runtime issue), could be also bnc#839074
Can't reproduce, and isn't bnc#839074
But I tried on my r600, can reproduce fdo#64810 and could fix it ... Yes, bnc#839074 is another issue
- ~ 1/2 build time
- ~ 1/5 - 1/6 binaries and -debuginfo
Always good ;-)
Is the only reason you don't want them fixed in 13.1 because they require 22 patches and upstream core devs don't want to talk to me anymore. Maybe they change their mind if one of the big distribution ships them ...
Maybe, but i'm not fond of openSUSE being testing ground for random, huge, not-upstream-ed/-eable patches...
They are upstreamable, welcomed and tested by Andreas Boll (was release manager for 9.0.x) but it is hard to find sb. who will push them ...
On 10.09.2013 12:25, Johannes Obermayr wrote:
Maybe the attached main diff is easier to review.
Maybe you are mad at me now and will just ignore me, but this was lost somewhere. Having it in the patch file(s) seems like a better idea anyway.
All other is just moving nv30, nv50 and nvc0 to nouveau subdir (~ 4.5 MB)...
You can split this big obvious moving into a separate patch. With this the "real" changes are in a smaller patch. And when you are successful in up streaming all of this, it is likely to be the first step. So we can drop it easily after that. And maybe you can split the patch even more!
Thanks, Tobias
Am Dienstag, 10. September 2013, 19:56:54 schrieb Tobias Klausmann:
On 10.09.2013 12:25, Johannes Obermayr wrote:
Maybe the attached main diff is easier to review.
Maybe you are mad at me now and will just ignore me, but this was lost somewhere. Having it in the patch file(s) seems like a better idea anyway.
I could swear it was attached ...
All other is just moving nv30, nv50 and nvc0 to nouveau subdir (~ 4.5 MB)...
You can split this big obvious moving into a separate patch. With this the "real" changes are in a smaller patch. And when you are successful in up streaming all of this, it is likely to be the first step. So we can drop it easily after that. And maybe you can split the patch even more!
https://github.com/jobermayr/mesa/commit/03073db
Btw. it is now https://build.opensuse.org/request/show/198331 (SR's message could be interesting ...)
Thanks, Tobias
On 10.09.2013 20:24, Johannes Obermayr wrote:
Am Dienstag, 10. September 2013, 19:56:54 schrieb Tobias Klausmann:
Maybe you are mad at me now and will just ignore me, but this was lost somewhere. Having it in the patch file(s) seems like a better idea anyway.
Meant a shotlog, sorry for the misunderstanding!
You can split this big obvious moving into a separate patch. With this the "real" changes are in a smaller patch. And when you are successful in up streaming all of this, it is likely to be the first step. So we can drop it easily after that. And maybe you can split the patch even more!
The better, just make this a single patch file for starters. The other one you had attached up there already. Just for easier maintance later not for review.
Btw. it is now https://build.opensuse.org/request/show/198331
Jep, changed the (now: ...) already in my last email :-) . I did replay here because of that, but you want to read the comment if you haven't already.
(Removing most directly CC'ed people, they can read it on the mainlinglist if there is any interest)
Tobias
-
Johannes Obermayr -
Stefan Dirsch -
Tobias Klausmann -
šumski