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==--