Radeon X.Org Driver Now Only Uses DRI3 By Default With GLAMOR

[dungeon]

bridgman
It is not, i don't misinterpreting the developer as i closed bug before anybody commented there.

So as he commented in time when it was closed i reopen it again.

I think Nicolai was saying "doesn't matter if it's working on fglrx now, is it broken on radeonsi ?

It was closed bug, why developers only read closed bugs is similar bumping method like you here better to post anything as comment because robot might eat it and then edit it... it is weird thing to do, but it seems that works on bugzilla too

dungeon usually reacts like that here too, that's probably his bug report.

Yeah, it is mine bug report So how i should react when nobody else commented on it in 2 years, i simply closed it . And after i closed it, then developer commented something so i reopen it up again.

I tought to remove trace from my dropbox too, but if someone will look at a bug here we go it is reopened again

And no one here answered my basic question again, how many years i need to wait even if i commented on this bug annualy - it seems it sits there for nothing

[starshipeleven]

And no one here answered my basic question again, how many years i need to wait even if i commented on this bug annualy - it seems it sits there for nothing

It's too low-priority probably, and bridgeman said they don't have a lot of manpower.

If they have to choose between "adding support for newer hardware and making sure it does not suck NOW" and "fixing older hardware drivers running old games over wine", you know what gets the priority.

[dungeon]

I opened 2 regression bugs recently, bisected them both and someone closed one when i commented that it works in master Ignoring the fact that bug title clearly mention llvm 3.9, that does not matter there it seems - if it works on master it is fine... And that another one is still there, author of bisected commit does not even commented on it yet

https://bugs.freedesktop.org/show_bug.cgi?id=97038

https://bugs.freedesktop.org/show_bug.cgi?id=97039

It seems to me really low traffic there and ignorance on high level... I am even sure why people does not wanna report bugs in these conditions

[bridgman]

I opened 2 regression bugs recently, bisected them both and someone closed one when i commented that it works in master Ignoring the fact that bug title clearly mention llvm 3.9, that does not matter there it seems - if it works on master it is fine...

The first one makes sense AFAICS - generally once a release has branched only (high impact, low risk) fixes are back-ported from master. If you feel strongly that 276051 meets those criteria then propose it be backported to 3.9 branch... but from a quick glance I see it touches 11 files (10 changed, 1 new) so I would not regard it as a candidate for back-porting unless it fixed an issue with broad impact.

And that another one is still there, author of bisected commit does not even commented on it yet

I don't understand the dialog in the second one at all... (first quote here is comment #3)... wouldn't it be comment #5 that Nicolai should ignore ? How is the author of the original commit supposed to know that you mentioned it in a ticket ?

Nicolai: Could you please try whether the attached patch fixes the problem for you?
smoki: No, still the same faults happens.
smoki: This works before 860b658b97f859ee7d0dd076a8ac0332601ffa65 So fixed.
Nicolai: I'm confused. You first wrote that 860b658b97f859ee7d0dd076a8ac0332601ffa65 is the commit which started the faults. Which one is it? Is Mesa master okay?
smoki: Why i closed this, have not idea... please ignore Comment 4 Yes Nicolai, bug is still there with current git of mesa and llvm.

[dungeon]

Things are 3 times slower on first bug, that kills perf completely... it is a major bug, Marek know it and said on irc that MUST to be backported... but opencl llvm guys seems not care much, but OK i guess they will do it ... so it is there where it is.

But someone who didn't even commented there closed a bug right in front on my face, so i start doing same thing if that is culture there

I don't understand the dialog in the second one at all... (first quote here is comment #3)... wouldn't it be comment #5 that Nicolai should ignore ? How is the author of the original commit supposed to know that you mentioned it in a ticket ?

I closed that bug too, when somone closed my first one i mentioned here with no reason... and comment was illogical BS on closure on both and again dev commented when it is closed... neither fglrx does matter on first neither comments to ignore does matter on second...

Anything does not matter when ignorance is high there and that is the reason why people won't file bugs... Anyone else can retrace that one which sits 2 years there, to see if it works or not... but nope i should speak to myself there and update bug annually like an idiot So yep, i fully undestand people why they won't do it

[bridgman]

Things are 3 times slower on first bug, that kills perf completely... it is a major bug, Marek know it and said on irc that MUST to be backported...

Does the slowdown affect a broad range of apps ? My initial impression was that it just affected a couple of very old apps...

but opencl llvm guys seems not care much, but OK i guess they will do it ... so it is there where it is.

Yep, the LLVM workflow isn't really attuned to customer support yet. IIRC it didn't even have point releases until recently when Tom and others volunteered to make them happen. It's getting better but still a ways to go.

Note that when you talk to the developer community you are not talking to a marketing department where everyone is forced to have the same views... there is going to be some variability in "how much they seem to care about you" depending on the alignment between the problem and the developer that responds... and if you make their lives difficult by getting snarky that doesn't help as much as you might expect.

But someone who didn't even commented there closed a bug right in front on my face, so i start doing same thing if that is culture there

Are you familiar with the term "cutting off your nose to spite your face" ? I understand your logic but don't recommend it

[dungeon]

Does the slowdown affect a broad range of apps ? My initial impression was that it just affected a couple of very old apps...

Nearly anything, yes... openarena there is just example.

Yep, the LLVM workflow isn't really attuned to customer support yet. IIRC it didn't even have point releases until recently when Tom and others volunteered to make them happen. It's getting better but still a ways to go.

Note that when you talk to the developer community you are not talking to a marketing department where everyone is forced to have the same views... there is going to be some variability in "how much they seem to care about you" depending on the alignment between the problem and the developer that responds... and if you make their lives difficult by getting snarky that doesn't help as much as you might expect.

I am not in question here, i don't even even complain with this and i understand difficulties, i just giving you my example why other people might resist to file bugs

[bridgman]

Nearly anything, yes... openarena there is just example.

Bleah... guessing a newer example would help if not already in the ticket. Openarena hasn't been the "killer app" for open source drivers for at least 3 years

I am not in question here, i don't even even complain with this and i understand difficulties, i just giving you my example why other people might resist to file bugs

Yep, understood... but at the end of the day it's a bit like lottery tickets... no guarantee that buying one will lead to winning, but not buying one greatly reduces your chances. The difference is that with bug tickets sometimes someone else will buy a ticket and share the winnings with you, but that's not as common as we would like.

And yes the analogy would be better if currency could be duplicated as easily as software.

[dungeon]

Bleah... guessing a newer example would help if not already in the ticket. Openarena hasn't been the "killer app" for open source drivers for at least 3 years

If it is not cards killer, It is still killer of APUs - 50 fps max on fastest APU isn't it? It sits down there capped by bandwidth And that when everything is fine on phoronix openarena benchmark But with a bug, now how much fps you have in its benchmark with a bug, probably 15 fps - that is how this looks like in practice. And let say Fury, if it have 300 fps it will go down bellow 100 fps... now that will be a bug, but mine is not isn't it

Yep, understood... but at the end of the day it's a bit like lottery tickets... no guarantee that buying one will lead to winning, but not buying one greatly reduces your chances. The difference is that with bug tickets sometimes someone else will buy a ticket and share the winnings with you, but that's not as common as we would like.

And yes the analogy would be better if currency could be duplicated as easily as software.

Well your next Ubuntu will i guess compile and use broken releases as mesa 12.0 against that llvm 3.9... So, neither mesa maintain stable branch recently, neither i see it in llvm much - ignorance utter high. And if i didn't reporting this, all Ubuntu users would run PPA anyway or just install pro

Nope, and now "i as bug reporter i became even quilty for mine behavior You see, instead of reporting bugs i would next time do something else" that is how logic goes for most

Remember recent Debian/Ubuntu switched to modesetting driver instead of intel driver for exact same reason, as there is no quality releases of it, and cos it is buggy and ignorant development of it Yes it is, with no quality releases your software is by definiton - shit

[bridgman]

Remember recent Debian/Ubuntu switched to modesetting driver instead of intel driver for exact same reason, as there is no quality releases of it, and cos it is buggy and ignorant development of it Yes it is, with no quality releases your software is by definiton - shit

Sure, but that's the whole point we are discussing here - whether to backport a complex change late in the release cycle or tell users of ioquake-based games to pick up WIP 3.9.x or 4.0. Both options suck in their own unique ways.

One of the ways that quality levels are managed in releases is by pushing back fairly hard on risky changes late in the cycle. I don't know what the right answer is in this specific case (although I'm leaning slightly in favour of back-porting since it doesn't seem that late in the cycle), just saying that unless you draw a line somewhere then releases never stabilize..