From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?) Date: Tue, 11 Jun 2019 18:18:53 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0463112292==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 2F309891DD for ; Tue, 11 Jun 2019 18:18:53 +0000 (UTC) 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: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0463112292== Content-Type: multipart/alternative; boundary="15602771330.CacA53.13042" Content-Transfer-Encoding: 7bit --15602771330.CacA53.13042 Date: Tue, 11 Jun 2019 18:18:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D110897 --- Comment #2 from Richard Thier --- Created attachment 144512 --> https://bugs.freedesktop.org/attachment.cgi?id=3D144512&action=3Dedit Error gone patch - but it is slow If I understand it well, HyperZ can be owned by only one process / owner and the ownership is transferred in the r300_blit.c file when clearing the buff= ers. I guess this is why closing an app having HyperZ can transfer it to an other one without restart. I have figured that this is also the place where buffer clearing takes place so I played around a bit here. Other releant files I have found are these: [code] src/gallium/drivers/r300/r300_context.c src/gallium/drivers/r300/r300_emit.c Update is in here - this sends stuff to card according to how docs say it:= =20 src/gallium/drivers/r300/r300_hyperz.c This is where hyperZ gets first activated: src/gallium/drivers/r300/r300_blit.c src/gallium/drivers/r300/r300_context.h Register naming (closely resembles r300 and 500 docs): src/gallium/drivers/r300/r300_reg.h [/code] See the attachment about what I am trying. With this attachment I do not see the issue anymore. I made this change by just looking at what the code does= and how it sets the zmask_clear and hiz_clear variables. As you can see first I= was just trying to set them myself, but later just commented out the part you s= ee. Interestingly there is a performance drop now - I mean a drop from an uncha= nged mesa without HYPERZ enabled to the changed one WITH hiz being enabled with = the environment variable. Does the fast clear or some things work even if the f= lag is not added? I am not sure what I do if I comment out the part that I did, but will look into the HyperZ update function to know what is being sent to the card registers. I see the registers and can see them in the docs, but I am somet= imes puzzled. Does the API between the kernel and user level send the enable Hyp= erZ bit in a different var and other parts of the same register in a different = var for example? I can also find it on my own I guess, but I need to compare ke= rnel and mesa side of the things and maybe someone just knows. This is how long I went so far - but I am still very much started only a bi= t. --=20 You are receiving this mail because: You are the assignee for the bug.= --15602771330.CacA53.13042 Date: Tue, 11 Jun 2019 18:18:53 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Commen= t # 2 on bug 11089= 7 from = Richard Thier
Created attach=
ment 144512 [details] [revie=
w]
Error gone patch - but it is slow

If I understand it well, HyperZ can be owned by only one process / owner and
the ownership is transferred in the r300_blit.c file when clearing the buff=
ers.

I guess this is why closing an app having HyperZ can transfer it to an other
one without restart. I have figured that this is also the place where buffer
clearing takes place so I played around a bit here.

Other releant files I have found are these:

[code]
src/gallium/drivers/r300/r300_context.c
src/gallium/drivers/r300/r300_emit.c
 Update is in here - this sends stuff to card according to how docs say it:=
=20
src/gallium/drivers/r300/r300_hyperz.c
 This is where hyperZ gets first activated:
src/gallium/drivers/r300/r300_blit.c
src/gallium/drivers/r300/r300_context.h
 Register naming (closely resembles r300 and 500 docs):
src/gallium/drivers/r300/r300_reg.h
[/code]

See the attachment about what I am trying. With this attachment I do not see
the issue anymore. I made this change by just looking at what the code does=
 and
how it sets the zmask_clear and hiz_clear variables. As you can see first I=
 was
just trying to set them myself, but later just commented out the part you s=
ee.

Interestingly there is a performance drop now - I mean a drop from an uncha=
nged
mesa without HYPERZ enabled to the changed one WITH hiz being enabled with =
the
environment variable. Does the fast clear or some things work even if the f=
lag
is not added?

I am not sure what I do if I comment out the part that I did, but will look
into the HyperZ update function to know what is being sent to the card
registers. I see the registers and can see them in the docs, but I am somet=
imes
puzzled. Does the API between the kernel and user level send the enable Hyp=
erZ
bit in a different var and other parts of the same register in a different =
var
for example? I can also find it on my own I guess, but I need to compare ke=
rnel
and mesa side of the things and maybe someone just knows.

This is how long I went so far - but I am still very much started only a bi=
t.


You are receiving this mail because:
  • You are the assignee for the bug.
= --15602771330.CacA53.13042-- --===============0463112292== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============0463112292==--