Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-14 Thread Nicolai Hähnle
On 12.06.2017 18:55, Marek Olšák wrote: Hi, This series only affects st/mesa, but other drivers can optionally be switched to this. I realized we don't need to flag _NEW flags for most states and we also don't need to call _mesa_update_state in most cases. Firstly, this series cleans up

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Timothy Arceri
On 14/06/17 02:15, Eero Tamminen wrote: Hi, On 13.06.2017 18:35, Ernst Sjöstrand wrote: does GfxBench v4 work on RadeonSI at all? GfxBench Manhattan, CarChase and tessellation tests require GL 4.x, its other tests (like Driver2) work with GL 3.x. Public GUI version is build with Qt. Why

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Eero Tamminen
Hi, On 13.06.2017 18:35, Ernst Sjöstrand wrote: does GfxBench v4 work on RadeonSI at all? GfxBench Manhattan, CarChase and tessellation tests require GL 4.x, its other tests (like Driver2) work with GL 3.x. Public GUI version is build with Qt. Why it wouldn't work? - Eero

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Ernst Sjöstrand
Hi, does GfxBench v4 work on RadeonSI at all? Regards //Ernst 2017-06-13 16:50 GMT+02:00 Eero Tamminen : > Hi, > > On 13.06.2017 16:23, Marek Olšák wrote: >> >> On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen >> wrote: >>> >>> On 13.06.2017

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Eero Tamminen
Hi, On 13.06.2017 16:23, Marek Olšák wrote: On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen wrote: On 13.06.2017 12:56, Marek Olšák wrote: Everything is here: git://people.freedesktop.org/~mareko/mesa state-optz Didn't see any changes in benchmark suites that

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Marek Olšák
On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen wrote: > Hi, > > On 13.06.2017 12:56, Marek Olšák wrote: >> >> Everything is here: >> >> git://people.freedesktop.org/~mareko/mesa state-optz > > > Didn't see any changes in benchmark suites that had tests which are >

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Eero Tamminen
Hi, On 13.06.2017 12:56, Marek Olšák wrote: Everything is here: git://people.freedesktop.org/~mareko/mesa state-optz Didn't see any changes in benchmark suites that had tests which are partially CPU bound. Everything was within variation on BYT, BSW, BDW, BXT & SKL. - Eero

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Marek Olšák
Everything is here: git://people.freedesktop.org/~mareko/mesa state-optz Marek On Tue, Jun 13, 2017 at 9:58 AM, Eero Tamminen wrote: > Hi, > > Do you have a branch I could check with our automation? > > On 13.06.2017 02:34, Marek Olšák wrote: >> >> Edmondo on IRC

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-13 Thread Eero Tamminen
Hi, Do you have a branch I could check with our automation? On 13.06.2017 02:34, Marek Olšák wrote: Edmondo on IRC reported that this series improves Civilization 5 performance and the improvement is not just tiny. A potentially interesting synthetic test-case for this could be "Driver2"

Re: [Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-12 Thread Marek Olšák
Hi, Edmondo on IRC reported that this series improves Civilization 5 performance and the improvement is not just tiny. Marek On Mon, Jun 12, 2017 at 6:55 PM, Marek Olšák wrote: > Hi, > > This series only affects st/mesa, but other drivers can optionally > be switched to

[Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

2017-06-12 Thread Marek Olšák
Hi, This series only affects st/mesa, but other drivers can optionally be switched to this. I realized we don't need to flag _NEW flags for most states and we also don't need to call _mesa_update_state in most cases. Firstly, this series cleans up _mesa_update_state_locked. A lot of the update