From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Tue, 22 Jul 2014 18:39:48 +0200 Message-ID: <53CE93D4.3010204@amd.com> References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> <53CE84AA.9030703@amd.com> <53CE8A57.2000803@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter , =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5p?= =?UTF-8?B?Zw==?= Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" List-Id: nouveau.vger.kernel.org PiBNYXliZSBJJ3ZlIG1peGVkIHRoaW5ncyB1cCBhIGJpdCBpbiBteSBkZXNjcmlwdGlvbi4gVGhl cmUgaXMKPiBmZW5jZV9zaWduYWwgd2hpY2ggdGhlIGltcGxlbWVudG9yL2V4cG9ydGVyIG9mIGEg ZmVuY2UgbXVzdCBjYWxsIHdoZW4KPiB0aGUgZmVuY2UgaXMgY29tcGxldGVkLiBJZiB0aGUgZXhw b3J0ZXIgaGFzIGFuIC0+ZW5hYmxlX3NpZ25hbGluZwo+IGNhbGxiYWNrIGl0IGNhbiBkZWxheSB0 aGF0IGNhbGwgdG8gZmVuY2Vfc2lnbmFsIGZvciBhcyBsb25nIGFzIGl0Cj4gd2lzaGVzIGFzIGxv bmcgYXMgZW5hYmxlX3NpZ25hbGluZyBpc24ndCBjYWxsZWQgeWV0LiBCdXQgdGhhdCdzIGp1c3QK PiB0aGUgb3B0aW1pemF0aW9uIHRvIG5vdCByZXF1aXJlZCBpcnFzIHRvIGJlIHR1cm5lZCBvbiBh bGwgdGhlIHRpbWUuCj4KPiBUaGUgb3RoZXIgZnVuY3Rpb24gaXMgZmVuY2VfaXNfc2lnbmFsZWQs IHdoaWNoIGlzIHVzZWQgYnkgY29kZSB0aGF0IGlzCj4gaW50ZXJlc3RlZCBpbiB0aGUgZmVuY2Ug c3RhdGUsIHRvZ2V0aGVyIHdpdGggZmVuY2Vfd2FpdCBpZiBpdCB3YW50cyB0bwo+IGJsb2NrIGFu ZCBub3QganVzdCB3YW50cyB0byBrbm93IHRoZSBtb21lbnRhcnkgZmVuY2Ugc3RhdGUuIEFsbCB0 aGUKPiBvdGhlciBmdW5jdGlvbnMgKHRoZSBzdHVmZiB0aGF0IGFkZHMgY2FsbGJhY2tzIGFuZCB0 aGUgdmFyaW91cyBfbG9ja2VkCj4gYW5kIG90aGVyIHZlcnNpb25zKSBhcmUganVzdCBmb3IgZmFu Y3kgc3BlY2lhbCBjYXNlcy4KV2VsbCB0aGF0J3MgcmF0aGVyIGJhZCwgY2F1c2UgSVJRcyBhcmVu J3QgcmVsaWFibGUgZW5vdWdoIG9uIFJhZGVvbiBIVyAKZm9yIHN1Y2ggYSB0aGluZy4gRXNwZWNp YWxseSBvbiBQcmltZSBzeXN0ZW1zIGFuZCBNYWNzLgoKVGhhdCdzIHdoeSB3ZSBoYXZlIHRoaXMg ZmFuY3kgSFovMiB0aW1lb3V0IG9uIGFsbCBmZW5jZSB3YWl0IG9wZXJhdGlvbnMgCnRvIG1hbnVh bGx5IGNoZWNrIGlmIHRoZSBmZW5jZSBpcyBzaWduYWxlZCBvciBub3QuCgpUbyBndWFyYW50ZWUg dGhhdCBhIGZlbmNlIGlzIHNpZ25hbGVkIGFmdGVyIGVuYWJsZV9zaWduYWxpbmcgaXMgY2FsbGVk IAp3ZSB3b3VsZCBuZWVkIHRvIGZpcmUgdXAgYSBrZXJuZWwgdGhyZWFkIHdoaWNoIHBlcmlvZGlj YWxseSBjYWxscyAKZmVuY2UtPnNpZ25hbGVkLgoKQ2hyaXN0aWFuLgoKQW0gMjIuMDcuMjAxNCAx ODoyMSwgc2NocmllYiBEYW5pZWwgVmV0dGVyOgo+IE9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDU6 NTkgUE0sIENocmlzdGlhbiBLw7ZuaWcKPiA8ZGVhdGhzaW1wbGVAdm9kYWZvbmUuZGU+IHdyb3Rl Ogo+PiBBbSAyMi4wNy4yMDE0IDE3OjQyLCBzY2hyaWViIERhbmllbCBWZXR0ZXI6Cj4+Cj4+PiBP biBUdWUsIEp1bCAyMiwgMjAxNCBhdCA1OjM1IFBNLCBDaHJpc3RpYW4gS8O2bmlnCj4+PiA8Y2hy aXN0aWFuLmtvZW5pZ0BhbWQuY29tPiB3cm90ZToKPj4+PiBEcml2ZXJzIGV4cG9ydGluZyBmZW5j ZXMgbmVlZCB0byBwcm92aWRlIGEgZmVuY2UtPnNpZ25hbGVkIGFuZCBhCj4+Pj4gZmVuY2UtPndh aXQKPj4+PiBmdW5jdGlvbiwgZXZlcnl0aGluZyBlbHNlIGxpa2UgZmVuY2UtPmVuYWJsZV9zaWdu YWxpbmcgb3IgY2FsbGluZwo+Pj4+IGZlbmNlX3NpZ25hbGVkKCkgZnJvbSB0aGUgZHJpdmVyIGlz IG9wdGlvbmFsLgo+Pj4+Cj4+Pj4gRHJpdmVycyB3YW50aW5nIHRvIHVzZSBleHBvcnRlZCBmZW5j ZXMgZG9uJ3QgY2FsbCBmZW5jZS0+c2lnbmFsZWQgb3IKPj4+PiBmZW5jZS0+d2FpdCBpbiBhdG9t aWMgb3IgaW50ZXJydXB0IGNvbnRleHQsIGFuZCBub3Qgd2l0aCBob2xkaW5nIGFueQo+Pj4+IGds b2JhbAo+Pj4+IGxvY2tpbmcgcHJpbWl0aXZlcyAobGlrZSBtbWFwX3NlbSBldGMuLi4pLiBIb2xk aW5nIGxvY2tpbmcgcHJpbWl0aXZlcwo+Pj4+IGxvY2FsCj4+Pj4gdG8gdGhlIGRyaXZlciBpcyBv aywgYXMgbG9uZyBhcyB0aGV5IGRvbid0IGNvbmZsaWN0IHdpdGggYW55dGhpbmcKPj4+PiBwb3Nz aWJsZQo+Pj4+IHVzZWQgYnkgdGhlaXIgb3duIGZlbmNlIGltcGxlbWVudGF0aW9uLgo+Pj4gV2Vs bCB0aGF0J3MgYWxtb3N0IHdoYXQgd2UgaGF2ZSByaWdodCBub3cgd2l0aCB0aGUgZXhjZXB0aW9u IHRoYXQKPj4+IGRyaXZlcnMgYXJlIGFsbG93ZWQgKGFjdHVhbGx5IG11c3QgZm9yIGNvcnJlY3Ru ZXNzIHdoZW4gdXBkYXRpbmcKPj4+IGZlbmNlcykgdGhlIHd3X211dGV4ZXMgZm9yIGRtYS1idWZz IChvciBvdGhlciBidWZmZXIgb2JqZWN0cykuCj4+Cj4+IEluIHRoaXMgY2FzZSBzb3JyeSBmb3Ig c28gbXVjaCBub2lzZS4gSSByZWFsbHkgaGF2ZW4ndCBsb29rZWQgaW4gc28gbXVjaAo+PiBkZXRh aWwgaW50byBhbnl0aGluZyBidXQgTWFhcnRlbidzIFJhZGVvbiBwYXRjaGVzLgo+Pgo+PiBCdXQg aG93IGRvZXMgdGhhdCB0aGVuIHdvcmsgcmlnaHQgbm93PyBNeSBpbXByZXNzaW9uIHdhcyB0aGF0 IGl0J3MgbWFuZGF0b3J5Cj4+IGZvciBkcml2ZXJzIHRvIGNhbGwgZmVuY2Vfc2lnbmFsZWQoKT8K PiBNYXliZSBJJ3ZlIG1peGVkIHRoaW5ncyB1cCBhIGJpdCBpbiBteSBkZXNjcmlwdGlvbi4gVGhl cmUgaXMKPiBmZW5jZV9zaWduYWwgd2hpY2ggdGhlIGltcGxlbWVudG9yL2V4cG9ydGVyIG9mIGEg ZmVuY2UgbXVzdCBjYWxsIHdoZW4KPiB0aGUgZmVuY2UgaXMgY29tcGxldGVkLiBJZiB0aGUgZXhw b3J0ZXIgaGFzIGFuIC0+ZW5hYmxlX3NpZ25hbGluZwo+IGNhbGxiYWNrIGl0IGNhbiBkZWxheSB0 aGF0IGNhbGwgdG8gZmVuY2Vfc2lnbmFsIGZvciBhcyBsb25nIGFzIGl0Cj4gd2lzaGVzIGFzIGxv bmcgYXMgZW5hYmxlX3NpZ25hbGluZyBpc24ndCBjYWxsZWQgeWV0LiBCdXQgdGhhdCdzIGp1c3QK PiB0aGUgb3B0aW1pemF0aW9uIHRvIG5vdCByZXF1aXJlZCBpcnFzIHRvIGJlIHR1cm5lZCBvbiBh bGwgdGhlIHRpbWUuCj4KPiBUaGUgb3RoZXIgZnVuY3Rpb24gaXMgZmVuY2VfaXNfc2lnbmFsZWQs IHdoaWNoIGlzIHVzZWQgYnkgY29kZSB0aGF0IGlzCj4gaW50ZXJlc3RlZCBpbiB0aGUgZmVuY2Ug c3RhdGUsIHRvZ2V0aGVyIHdpdGggZmVuY2Vfd2FpdCBpZiBpdCB3YW50cyB0bwo+IGJsb2NrIGFu ZCBub3QganVzdCB3YW50cyB0byBrbm93IHRoZSBtb21lbnRhcnkgZmVuY2Ugc3RhdGUuIEFsbCB0 aGUKPiBvdGhlciBmdW5jdGlvbnMgKHRoZSBzdHVmZiB0aGF0IGFkZHMgY2FsbGJhY2tzIGFuZCB0 aGUgdmFyaW91cyBfbG9ja2VkCj4gYW5kIG90aGVyIHZlcnNpb25zKSBhcmUganVzdCBmb3IgZmFu Y3kgc3BlY2lhbCBjYXNlcy4KPgo+Pj4gTG9ja2luZwo+Pj4gY29ycmVjdG5lc3MgaXMgZW5mb3Jj ZWQgd2l0aCBzb21lIGV4dHJlbWVseSBuYXN0eSBsb2NrZGVwIGFubm90YXRpb25zCj4+PiArIGFk ZGl0aW9uYWwgZGVidWdnaW5nIGluZnJhc3RydWN0dXJlIGVuYWJsZWQgd2l0aAo+Pj4gQ09ORklH X0RFQlVHX1dXX01VVEVYX1NMT1dQQVRILiBXZSByZWFsbHkgbmVlZCB0byBiZSBhYmxlIHRvIGhv bGQKPj4+IGRtYS1idWYgd3dfbXV0ZXhlcyB3aGlsZSB1cGRhdGluZyBmZW5jZXMgb3Igd2FpdGlu ZyBmb3IgdGhlbS4gQW5kCj4+PiBvYnZpb3VzbHkgZm9yIC0+d2FpdCB3ZSBuZWVkIG5vbi1hdG9t aWMgY29udGV4dCwgbm90IGp1c3QKPj4+IG5vbi1pbnRlcnJ1cHQuCj4+Cj4+IFNvdW5kcyBtb3N0 bHkgcmVhc29uYWJsZSwgYnV0IGZvciBob2xkaW5nIHRoZSBkbWEtYnVmIHd3X211dGV4LCB3b3Vs ZG4ndCBiZQo+PiBhbiBSQ1UgYmUgbW9yZSBhcHByb3ByaWF0ZSBoZXJlPyBFLmcuIGFyZW4ndCB3 ZSBqdXN0IGludGVyZXN0ZWQgdGhhdCB0aGUKPj4gY3VycmVudCBhc3NpZ25lZCBmZW5jZSBhdCBz b21lIHBvaW50IGlzIHNpZ25hbGVkPwo+IFllYWgsIGFzIGFuIG9wdGltaXphdGlvbiB5b3UgY2Fu IGdldCB0aGUgc2V0IG9mIGN1cnJlbnRseSBhdHRhY2hlZAo+IGZlbmNlcyB0byBhIGRtYS1idWYg d2l0aCBqdXN0IHJjdS4gQnV0IGlmIHlvdSB1cGRhdGUgdGhlIHNldCBvZiBmZW5jZXMKPiBhdHRh Y2hlZCB0byBhIGRtYS1idWYgKGUuZy4gcmFkZW9uIGJsaXRzIHRoZSBuZXdseSByZW5kZXJlZCBm cmFtZSB0byBhCj4gZG1hLWJ1ZiBleHBvcnRlZCBieSBpOTE1IGZvciBzY2Fub3V0IG9uIGk5MTUp IHRoZW4geW91IG5lZWQgYSB3cml0ZQo+IGxvY2sgb24gdGhhdCBidWZmZXIuIFdoaWNoIGlzIHdo YXQgdGhlIHd3X211dGV4IGlzIGZvciwgdG8gbWFrZSBzdXJlCj4gdGhhdCB5b3UgZG9uJ3QgZGVh ZGxvY2sgd2l0aCBpOTE1IGRvaW5nIGNvbmN1cnJlbnQgb3BzIG9uIHRoZSBzYW1lCj4gdW5kZXJs eWluZyBidWZmZXIuCj4KPj4gU29tZXRoaW5nIGxpa2UgZ3JhYiB3d19tdXRleGVzLCBncmFiIGEg cmVmZXJlbmNlIHRvIHRoZSBjdXJyZW50IGZlbmNlCj4+IG9iamVjdCwgcmVsZWFzZSB3d19tdXRl eCwgd2FpdCBmb3IgZmVuY2UsIHJlbGVhc2UgcmVmZXJlbmNlIHRvIHRoZSBmZW5jZQo+PiBvYmpl Y3QuCj4gWWVhaCwgaWYgdGhlIG9ubHkgdGhpbmcgeW91IHdhbnQgdG8gZG8gaXMgd2FpdCBmb3Ig ZmVuY2VzLCB0aGVuIHRoZQo+IHJjdS1wcm90ZWN0ZWQgZmVuY2UgcmVmIGdyYWJiaW5nICsgbG9j a2xlc3Mgd2FpdGluZyBpcyBhbGwgeW91IG5lZWQuCj4gQnV0IGUuZy4gaW4gYW4gZXhlY2J1ZiB5 b3UgYWxzbyBuZWVkIHRvIHVwZGF0ZSBmZW5jZXMgYW5kIG1heWJlIGRlZXAKPiBkb3duIGluIHRo ZSByZXNlcnZhdGlvbiBjb2RlIHlvdSBub3RpY2UgdGhhdCB5b3UgbmVlZCB0byBldmljdCBzb21l Cj4gc3R1ZmYgYW5kIHNvIG5lZWQgdG8gd2FpdCBvbiBzb21lIG90aGVyIGd1eSB0byBmaW5pc2gs IGFuZCBpdCdzIHRvbwo+IGNvbXBsaWNhdGVkIHRvIGRyb3AgYW5kIHJlYWNxdWlyZSBhbGwgdGhl IGxvY2tzLiBPciB5b3Ugc2ltcGx5IG5lZWQgdG8KPiBkbyBhIGJsb2NraW5nIHdhaXQgb24gb3Ro ZXIgZ3B1cyAoYmVjYXVzZSB0aGVyZSdzIG5vIGRpcmVjdCBodyBzeW5jCj4gbWVjaGFuaXNtKSBh bmQgYWdhaW4gZHJvcHBpbmcgbG9ja3Mgd291bGQgbmVlZGxlc3NseSBjb21wbGljYXRlIHRoZQo+ IGNvZGUuIFNvIEkgdGhpbmsgd2Ugc2hvdWxkIGFsbG93IHRoaXMganVzdCB0byBhdm9pZCB0b28g aGFpcnkvYnJpdHRsZQo+IChhbmQgYWxtb3N0IGRlZmluaXRlbHkgbGl0dGxlIHRlc3RlZCBjb2Rl KSBpbiBkcml2ZXJzLgo+Cj4gQWZhaWsgdGhpcyBpcyBhbHNvIHRoZSBzYW1lIHdheSB0dG0gY3Vy cmVudGx5IGhhbmRsZXMgdGhpbmdzIHdydAo+IGJ1ZmZlciByZXNlcnZhdGlvbiBhbmQgZXZpY3Rp b24uCj4KPj4+IEFncmVlZCB0aGF0IGFueSBzaGFyZWQgbG9ja3MgYXJlIG91dCBvZiB0aGUgd2F5 IChlc3BlY2lhbGx5IHN0dWZmIGxpa2UKPj4+IGRldi0+c3RydWN0X211dGV4IG9yIG90aGVyIG5v bi1zdHJpY3RseSBkcml2ZXItcHJpdmF0ZSBzdHVmZiwgaTkxNSBpcwo+Pj4gcmVhbGx5IGJhZCBo ZXJlIHN0aWxsKS4KPj4KPj4gWWVhaCB0aGF0J3MgYWxzbyBhbiBwb2ludCBJJ3ZlIHdhbnRlZCB0 byBub3RlIG9uIE1hYXJ0ZW5zIHBhdGNoLiBSYWRlb24KPj4gZ3JhYnMgdGhlIHJlYWQgc2lkZSBv ZiBpdCdzIGV4Y2x1c2l2ZSBzZW1hcGhvcmUgd2hpbGUgd2FpdGluZyBmb3IgZmVuY2VzCj4+IChi ZWNhdXNlIGl0IGFzc3VtZXMgdGhhdCB0aGUgZmVuY2UgaXQgd2FpdHMgZm9yIGlzIGEgUmFkZW9u IGZlbmNlKS4KPj4KPj4gQXNzdW1pbmcgdGhhdCB3ZSBuZWVkIHRvIHdhaXQgaW4gYm90aCBkaXJl Y3Rpb25zIHdpdGggUHJpbWUgKGUuZy4gSW50ZWwKPj4gZHJpdmVyIG5lZWRzIHRvIHdhaXQgZm9y IFJhZGVvbiB0byBmaW5pc2ggcmVuZGVyaW5nIGFuZCBSYWRlb24gbmVlZHMgdG8gd2FpdAo+PiBm b3IgSW50ZWwgdG8gZmluaXNoIGRpc3BsYXlpbmcpLCB0aGlzIG1pZ2h0IGJlY29tZSBhIHBlcmZl Y3QgZXhhbXBsZSBvZgo+PiBsb2NraW5nIGludmVyc2lvbi4KPiBmZW5jZSB1cGRhdGVzIGFyZSBh dG9taWMgb24gYSBkbWEtYnVmLCBwcm90ZWN0ZWQgYnkgd3dfbXV0ZXguIFRoZSBuZWF0Cj4gdHJp Y2sgb2Ygd3dfbXV0ZXggaXMgdGhhdCB0aGV5IGVuZm9yY2UgYSBnbG9iYWwgb3JkZXJpbmcsIHNv IGluIHlvdXIKPiBzY2VuYXJpbyBlaXRoZXIgaTkxNSBvciByYWRlb24gd291bGQgYmUgZmlyc3Qg YW5kIHlvdSBjYW4ndCBkZWFkbG9jay4KPiBUaGVyZSBpcyBubyB3YXkgdG8gaW50ZXJsZWF2ZSBh bnl0aGluZyBldmVuIGlmIHlvdSBoYXZlIGxvdHMgb2YKPiBidWZmZXJzIHNoYXJlZCBiZXR3ZWVu IGk5MTUvcmFkZW9uLiBXcnQgZGVhZGxvY2tpbmcgaXQncyBleGFjdGx5IHRoZQo+IHNhbWUgZ3Vh cmFudGVlcyBhcyB0aGUgbWFnaWMgdHRtIHByb3ZpZGVzIGZvciBqdXN0IG9uZSBkcml2ZXIgd2l0 aAo+IGNvbmN1cnJlbnQgY29tbWFuZCBzdWJtaXNzaW9uIHNpbmNlIGl0J3MgdGhlIHNhbWUgaWRl YS4KPgo+Pj4gU28gZnJvbSB0aGUgY29yZSBmZW5jZSBmcmFtZXdvcmsgSSB0aGluayB3ZSBhbHJl YWR5IGhhdmUgZXhhY3RseSB0aGlzLAo+Pj4gYW5kIHdlIG9ubHkgbmVlZCB0byBhZGp1c3QgdGhl IHJhZGVvbiBpbXBsZW1lbnRhdGlvbiBhIGJpdCB0byBtYWtlIGl0Cj4+PiBsZXNzIHJpc2t5IGFu ZCBpbnZhc2l2ZSB0byB0aGUgcmFkZW9uIGRyaXZlciBsb2dpYy4KPj4KPj4gQWdyZWUuIFdlbGwg dGhlIGJpZ2dlc3QgcHJvYmxlbSBJIHNlZSBpcyB0aGF0IGV4Y2x1c2l2ZSBzZW1hcGhvcmUgSSBu ZWVkIHRvCj4+IHRha2Ugd2hlbiBhbnl0aGluZyBjYWxscyBpbnRvIHRoZSBkcml2ZXIuIEZvciB0 aGUgZmVuY2UgY29kZSBJIG5lZWQgdG8gbW92ZQo+PiB0aGF0IGRvd24gaW50byB0aGUgZmVuY2Ut PnNpZ25hbGVkIGhhbmRsZXIsIGNhdXNlIHRoYXQgbm93IGNhbiBiZSBjYWxsZWQKPj4gZnJvbSBv dXRzaWRlIHRoZSBkcml2ZXIuCj4+Cj4+IE1hYXJ0ZW4gc29sdmVkIHRoaXMgYnkgdGVsbGluZyB0 aGUgZHJpdmVyIGluIHRoZSBsb2NrdXAgaGFuZGxlciAod2hlcmUgd2UKPj4gZ3JhYiB0aGUgd3Jp dGUgc2lkZSBvZiB0aGUgZXhjbHVzaXZlIGxvY2spIHRoYXQgYWxsIGludGVycnVwdHMgYXJlIGFs cmVhZHkKPj4gZW5hYmxlZCwgc28gdGhhdCBmZW5jZS0+c2lnbmFsZWQgaG9wZWZ1bGx5IHdvdWxk bid0IG1lc3Mgd2l0aCB0aGUgaGFyZHdhcmUKPj4gYXQgYWxsLiBXaGlsZSB0aGlzIHByb2JhYmx5 IHdvcmtzLCBpdCBqdXN0IGxlYXZlcyBtZSB3aXRoIGEgZmVlbGluZyB0aGF0IHdlCj4+IGFyZSBk b2luZyBzb21ldGhpbmcgd3JvbmcgaGVyZS4KPiBJJ20gbm90IHZlcnNlZCBvbiB0aGUgZGV0YWls cyBpbiByZWFkb24sIGJ1dCBvbiBpOTE1IHdlIGNhbiBhdHRhY2ggYQo+IG1lbW9yeSBsb2NhdGlv biBhbmQgY29va2llIHZhbHVlIHRvIGVhY2ggZmVuY2UgYW5kIGp1c3QgZG8gYSBtZW1vcnkKPiBm ZXRjaCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgdGhlIGZlbmNlIGhhcyBwYXNzZWQgb3Igbm90LiBT byBubyBsb2NraW5nCj4gbmVlZGVkIGF0IGFsbC4gT2YgY291cnNlIHRoZSBmZW5jZSBpdHNlbGYg bmVlZHMgdG8gbG9jayBhIHJlZmVyZW5jZQo+IG9udG8gdGhhdCBtZW1vcnkgbG9jYXRpb24sIHdo aWNoIGlzIGEgbmVhdCBwaWVjZSBvZiBpbnRlZ3JhdGlvbiB3b3JrCj4gdGhhdCB3ZSBzdGlsbCBu ZWVkIHRvIHRhY2tsZSBpbiBzb21lIGNhc2VzIC0gdGhlcmUncyBjb25mbGljdGluZyBwYXRjaAo+ IHNlcmllcyBhbGwgb3ZlciB0aGlzIDstKQo+Cj4gQnV0IGxpa2UgSSd2ZSBzYWlkIGZlbmNlLT5z aWduYWxlZCBpcyBvcHRpb25hbCBzbyB5b3UgZG9uJ3QgbmVlZCB0aGlzCj4gbmVjZXNzYXJpbHks IGFzIGxvbmcgYXMgcmFkZW9uIGV2ZW50dWFsbHkgY2FsbHMgZmVuY2Vfc2lnbmFsZWQgb25jZQo+ IHRoZSBmZW5jZSBoYXMgY29tcGxldGVkLgo+IC1EYW5pZWwKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRl dmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21h aWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756061AbaGVQkE (ORCPT ); Tue, 22 Jul 2014 12:40:04 -0400 Received: from mail-bn1lp0141.outbound.protection.outlook.com ([207.46.163.141]:42975 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755995AbaGVQj7 convert rfc822-to-8bit (ORCPT ); Tue, 22 Jul 2014 12:39:59 -0400 X-WSS-ID: 0N94GYG-08-8OM-02 X-M-MSG: Message-ID: <53CE93D4.3010204@amd.com> Date: Tue, 22 Jul 2014 18:39:48 +0200 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Vetter , =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5p?= =?UTF-8?B?Zw==?= CC: Thomas Hellstrom , nouveau , LKML , dri-devel , "Deucher, Alexander" , Ben Skeggs Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> <53CE84AA.9030703@amd.com> <53CE8A57.2000803@vodafone.de> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.224.155.194] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(428002)(24454002)(377454003)(51704005)(199002)(189002)(76482001)(106466001)(19580395003)(87936001)(80316001)(74662001)(65816999)(92726001)(77982001)(81542001)(95666004)(74502001)(81342001)(36756003)(23676002)(92566001)(85182001)(65806001)(4396001)(65956001)(59896001)(83506001)(50466002)(87266999)(19580405001)(97736001)(83322001)(21056001)(105586002)(64706001)(54356999)(107046002)(83072002)(84676001)(46102001)(86362001)(80022001)(93886003)(44976005)(85852003)(31966008)(47776003)(33656002)(20776003)(99396002)(85306003)(50986999)(101416001)(68736004)(85202003)(102836001)(79102001)(64126003)(76176999);DIR:OUT;SFP:;SCL:1;SRVR:BY2PR02MB042;H:atltwp02.amd.com;FPR:;MLV:sfv;PTR:InfoDomainNonexistent;MX:1;LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02801ACE41 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=Christian.Koenig@amd.com; X-OriginatorOrg: amd4.onmicrosoft.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Maybe I've mixed things up a bit in my description. There is > fence_signal which the implementor/exporter of a fence must call when > the fence is completed. If the exporter has an ->enable_signaling > callback it can delay that call to fence_signal for as long as it > wishes as long as enable_signaling isn't called yet. But that's just > the optimization to not required irqs to be turned on all the time. > > The other function is fence_is_signaled, which is used by code that is > interested in the fence state, together with fence_wait if it wants to > block and not just wants to know the momentary fence state. All the > other functions (the stuff that adds callbacks and the various _locked > and other versions) are just for fancy special cases. Well that's rather bad, cause IRQs aren't reliable enough on Radeon HW for such a thing. Especially on Prime systems and Macs. That's why we have this fancy HZ/2 timeout on all fence wait operations to manually check if the fence is signaled or not. To guarantee that a fence is signaled after enable_signaling is called we would need to fire up a kernel thread which periodically calls fence->signaled. Christian. Am 22.07.2014 18:21, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:59 PM, Christian König > wrote: >> Am 22.07.2014 17:42, schrieb Daniel Vetter: >> >>> On Tue, Jul 22, 2014 at 5:35 PM, Christian König >>> wrote: >>>> Drivers exporting fences need to provide a fence->signaled and a >>>> fence->wait >>>> function, everything else like fence->enable_signaling or calling >>>> fence_signaled() from the driver is optional. >>>> >>>> Drivers wanting to use exported fences don't call fence->signaled or >>>> fence->wait in atomic or interrupt context, and not with holding any >>>> global >>>> locking primitives (like mmap_sem etc...). Holding locking primitives >>>> local >>>> to the driver is ok, as long as they don't conflict with anything >>>> possible >>>> used by their own fence implementation. >>> Well that's almost what we have right now with the exception that >>> drivers are allowed (actually must for correctness when updating >>> fences) the ww_mutexes for dma-bufs (or other buffer objects). >> >> In this case sorry for so much noise. I really haven't looked in so much >> detail into anything but Maarten's Radeon patches. >> >> But how does that then work right now? My impression was that it's mandatory >> for drivers to call fence_signaled()? > Maybe I've mixed things up a bit in my description. There is > fence_signal which the implementor/exporter of a fence must call when > the fence is completed. If the exporter has an ->enable_signaling > callback it can delay that call to fence_signal for as long as it > wishes as long as enable_signaling isn't called yet. But that's just > the optimization to not required irqs to be turned on all the time. > > The other function is fence_is_signaled, which is used by code that is > interested in the fence state, together with fence_wait if it wants to > block and not just wants to know the momentary fence state. All the > other functions (the stuff that adds callbacks and the various _locked > and other versions) are just for fancy special cases. > >>> Locking >>> correctness is enforced with some extremely nasty lockdep annotations >>> + additional debugging infrastructure enabled with >>> CONFIG_DEBUG_WW_MUTEX_SLOWPATH. We really need to be able to hold >>> dma-buf ww_mutexes while updating fences or waiting for them. And >>> obviously for ->wait we need non-atomic context, not just >>> non-interrupt. >> >> Sounds mostly reasonable, but for holding the dma-buf ww_mutex, wouldn't be >> an RCU be more appropriate here? E.g. aren't we just interested that the >> current assigned fence at some point is signaled? > Yeah, as an optimization you can get the set of currently attached > fences to a dma-buf with just rcu. But if you update the set of fences > attached to a dma-buf (e.g. radeon blits the newly rendered frame to a > dma-buf exported by i915 for scanout on i915) then you need a write > lock on that buffer. Which is what the ww_mutex is for, to make sure > that you don't deadlock with i915 doing concurrent ops on the same > underlying buffer. > >> Something like grab ww_mutexes, grab a reference to the current fence >> object, release ww_mutex, wait for fence, release reference to the fence >> object. > Yeah, if the only thing you want to do is wait for fences, then the > rcu-protected fence ref grabbing + lockless waiting is all you need. > But e.g. in an execbuf you also need to update fences and maybe deep > down in the reservation code you notice that you need to evict some > stuff and so need to wait on some other guy to finish, and it's too > complicated to drop and reacquire all the locks. Or you simply need to > do a blocking wait on other gpus (because there's no direct hw sync > mechanism) and again dropping locks would needlessly complicate the > code. So I think we should allow this just to avoid too hairy/brittle > (and almost definitely little tested code) in drivers. > > Afaik this is also the same way ttm currently handles things wrt > buffer reservation and eviction. > >>> Agreed that any shared locks are out of the way (especially stuff like >>> dev->struct_mutex or other non-strictly driver-private stuff, i915 is >>> really bad here still). >> >> Yeah that's also an point I've wanted to note on Maartens patch. Radeon >> grabs the read side of it's exclusive semaphore while waiting for fences >> (because it assumes that the fence it waits for is a Radeon fence). >> >> Assuming that we need to wait in both directions with Prime (e.g. Intel >> driver needs to wait for Radeon to finish rendering and Radeon needs to wait >> for Intel to finish displaying), this might become a perfect example of >> locking inversion. > fence updates are atomic on a dma-buf, protected by ww_mutex. The neat > trick of ww_mutex is that they enforce a global ordering, so in your > scenario either i915 or radeon would be first and you can't deadlock. > There is no way to interleave anything even if you have lots of > buffers shared between i915/radeon. Wrt deadlocking it's exactly the > same guarantees as the magic ttm provides for just one driver with > concurrent command submission since it's the same idea. > >>> So from the core fence framework I think we already have exactly this, >>> and we only need to adjust the radeon implementation a bit to make it >>> less risky and invasive to the radeon driver logic. >> >> Agree. Well the biggest problem I see is that exclusive semaphore I need to >> take when anything calls into the driver. For the fence code I need to move >> that down into the fence->signaled handler, cause that now can be called >> from outside the driver. >> >> Maarten solved this by telling the driver in the lockup handler (where we >> grab the write side of the exclusive lock) that all interrupts are already >> enabled, so that fence->signaled hopefully wouldn't mess with the hardware >> at all. While this probably works, it just leaves me with a feeling that we >> are doing something wrong here. > I'm not versed on the details in readon, but on i915 we can attach a > memory location and cookie value to each fence and just do a memory > fetch to figure out whether the fence has passed or not. So no locking > needed at all. Of course the fence itself needs to lock a reference > onto that memory location, which is a neat piece of integration work > that we still need to tackle in some cases - there's conflicting patch > series all over this ;-) > > But like I've said fence->signaled is optional so you don't need this > necessarily, as long as radeon eventually calls fence_signaled once > the fence has completed. > -Daniel