[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #72 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/388. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #71 from Richard Thier --- Made a similar writeup on this topic too: http://ballmerpeak.web.elte.hu/devblog/debugging-hyperz-and-fixing-a-radeon-drm-linux-kernel-module.html Also tried to document all relevant information if it ever helps anyone. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Richard Thier changed: What|Removed |Added Attachment #144572|0 |1 is obsolete|| --- Comment #70 from Richard Thier --- Created attachment 144573 --> https://bugs.freedesktop.org/attachment.cgi?id=144573=edit Sent patch I have tried, let me know if it didn't succeed or anything need to be changed for next time. For reference, this was the command I used (with this attached file) git send-email 0001-drm-radeon-Fix-rs400_gpu_init-for-ATI-mobility-radeo.patch --to='amd-...@lists.freedesktop.org' -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #69 from Marek Olšák --- Can you send it to amd-...@lists.freedesktop.org adding the "drm/radeon: " commit prefix and your Signed-off-by? Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Richard Thier changed: What|Removed |Added Attachment #144559|0 |1 is obsolete|| Attachment #144560|0 |1 is obsolete|| --- Comment #68 from Richard Thier --- Created attachment 144572 --> https://bugs.freedesktop.org/attachment.cgi?id=144572=edit Added back rs400_mc_wait_for_idle - maybe final patch? I was actually thinking about keeping that part, but it was a do-or-don't decision. Added a patch that is basically variant 1, but keeps the mentioned rs400_mc_wait_for_idle call parts untouched. Also I have obsoleted the earlier two variants. Is this final patch for this issue maybe? I do not know if anyone still have glitches with HyperZ on r300 (I do not have any at all), but this kind of heavy glitches should at least go away now completely for everyone. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #67 from Marek Olšák --- Keep the rs400_mc_wait_for_idle call. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Michel Dänzer changed: What|Removed |Added CC|mic...@daenzer.net | --- Comment #66 from Michel Dänzer --- Removing myself from the CC list again, as I get updates via the mailing list anyway. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #65 from Richard Thier --- Okay. Then variant 1 is the way to go I think. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #64 from Marek Olšák --- rs400, which includes rc400, is not r400. It's r300. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #63 from cosiek...@o2.pl --- (In reply to Richard Thier from comment #58) > Also there was one time where things were working for me before changes but > I do not know what the pipe value was back then. So yes, there is SOME > chance that this register can also return 1 in my case too, but it seems > most of the time (99% at least if not 100%) it returns 3. It would be lovely if you could replicate that… Also this is consistent with your mesa testing earlier. That sometimes when you compiled mesa with your patches and stock mesa they were both working/not working. But that means that this weird behaviour: 17.1.2-1 crash(different) 17.1.1-1 crash(different) 17.1.0-1 crash(different) 17.0.5-1 working 17.0.4-2 working 17.0.4-1 crash 17.0.3-2 working 17.0.3-1 crash 17.0.2-2 working 17.0.2-1 crash 17.0.1-2 crash 17.0.1-1 crash 17.0.0-3 crash 17.0.0-2 crash 17.0.0-1 crash 13.0.4-2 crash is something different than this bug. But I don't believe that there were any changes between for example 17.0.3-1 and 17.0.3-2… Sooo, reboot, cold start, suspend don't change anything with pipe numbers? Also if you take a look at my old piglit tests, there were definitely more bugs with HyperZ on. Also great work so far! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #62 from Richard Thier --- Tested both versions and both work for me. Performance gain when using HyperZ is around 5-10% for me (that is sometimes just 2-4 FPS, sometimes more). gb_pipes are reported as 1 now as it should be. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #61 from Richard Thier --- Created attachment 144560 --> https://bugs.freedesktop.org/attachment.cgi?id=144560=edit Fix variant 2 (special case pipe number for 0x5a62) Added the second fix variation I've imagined. I am still compiling this so it is not tested yet, but this should work just as well. After thinking about it now, actually I tend to favor this latter one as being more clean, because I have no idea what the other rs400 cards do if I just forward to the r300 init code. My card works with that variant, but this is more sane maybe? The bad thing is that this literally only fixes those cards that do have 0x5a62 as their rdev->pdev->device value. So "Fix variant 1" might fix more cards if they have a similar issue and "Fix variant 2" should fix only this one and should not break unrelated cards. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #60 from Richard Thier --- Created attachment 144559 --> https://bugs.freedesktop.org/attachment.cgi?id=144559=edit Fix variant 1 (delegate to r300 init) Added a possible drm patch for kernel source tree. This version is the one that delegates the rs400_gpu_init call to the r300_gpu_init directly. Tested at my machine only so far. Tried to comment things as good as possible. I will make an other variant soon! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #59 from Richard Thier --- > the glitches are the same (I know about some already), > everything works that worked before... I was kinda hoping maybe some glitches I know can go away if the init code does the r300_init but that is not the case sadly. Quite the same overall system, but now have 1 pipes reported in dmesg. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #58 from Richard Thier --- I still have some dmesg logs around from my other debugging session and in every one of those I get 3 pipes despite different kernel versions from 4.4 to latest 5.x Also looking at git blame I can see that relevant code paths were last touched 10 years ago with a big drm related commit. So nothing has changed in the code it seems. Ok... I didn't check if the register number in the header is changed or not, just hoped not, but the code itself is doing the same 10 year old things here. Even the FIXME saying if this is good or not (when calling r420_pipes_init in rs400_init) is that old. [drm] initializing kernel modesetting (RS400 0x1002:0x5A62 0x1043:0x1392) ^^You seem to be also 5A62 here. In the code of r420_pipes_init, there are some hardcoded cases for some other similar values that force a single-pipe instead of reading from the register but you do not fall into those. The last two numbers are different in your case, but that does not count for that code path that decides the pipe number - except if the small variance in the last two means that your card gives back proper values in the register from which you can read the pipe num. Btw running with r300_init call instead of the r420 pipe initializaion is going good so far: performance is the same, the glitches are the same (I know about some already), everything works that worked before... One possible solution might be to just use r300_init for r400, but I have no idea if that breaks some r400 cards. I only have my RC410 but no other... An other appoach is to add one more special cases for the r420_pipes_init that specifically checks for 5A62 and forces a single pipeline despite what is read from the register. Also there was one time where things were working for me before changes but I do not know what the pipe value was back then. So yes, there is SOME chance that this register can also return 1 in my case too, but it seems most of the time (99% at least if not 100%) it returns 3. I will prepare both patches and then let others decide which direction to take. I think taking the r300_init direction is maybe better because of hopeful backwards compatibility in general. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #57 from cosiek...@o2.pl --- 4.14.124: 1 quad pipes, 1 z pipes initialized. 4.19.49: 1 quad pipes, 1 z pipes initialized. 4.20.17: 1 quad pipes, 1 z pipes initialized. 5.0.21: 1 quad pipes, 1 z pipes initialized. 5.1.8: 1 quad pipes, 1 z pipes initialized. Richard Thier, if we have the same graphic card then why do you sometimes get "3 quad pipes, 1 z pipes initialized."? Can you test on different kernel versions? Do you always have this 3 quad pipes or it's random? I'm happy to help further :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #56 from Richard Thier --- (In reply to cosiekvfj from comment #54) > Created attachment 144558 [details] > dmesg log > > [ 14.303343] [drm] radeon: 1 quad pipes, 1 z pipes initialized. This is really interesting! It tells us why it works in your case (the 1 quad pipe is reported "properly"), but I have no idea why it is reported properly. I see you are using 4.x kernel so there might be changes - or for some reason your card returns proper values from the registers the driver read from and mine does not. Thank you for the information! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #55 from Richard Thier --- (In reply to Dieter Nützel from comment #53) > If you do NOT 'make mrproper' and change only radeon/amdgpu stuff it should > only take some minutes (seconds) on your system/CPU. I was dumb-enough that last time I have cleaned the kernel build dir of mine to save some space haha. This way it took around 50 minutes. > > This seems to be the real core of the issue. > > We hear from you. ;-) I am testing right now, at least the system and X have started but will try some games and look for what the logs say. I have also added some extra logging for my liking just to gain more insightful information as I actually have two ideas for fixing this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #54 from cosiek...@o2.pl --- Created attachment 144558 --> https://bugs.freedesktop.org/attachment.cgi?id=144558=edit dmesg log [ 14.303343] [drm] radeon: 1 quad pipes, 1 z pipes initialized. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #53 from Dieter Nützel --- (In reply to Richard Thier from comment #52) > (In reply to Marek Olšák from comment #45) > > The problem might be in the kernel. See function rs400_gpu_init. I think it > > should call r300_gpu_init instead of r420_pipes_init. > > Aaaah Am I this blind? Now I see exactly this. > > Also in dmesg log I see RS400 being written out so yes I end up here and > according to my own links this seem to be the problem that the > rs400_gpu_init should not do the r420_pipes_init, because it is not r420 > yet > Now after investigating I think I should indeed end up here with the > rs400_asic, but yes the 420 pipe setup is wrong - at least for my card. > > I will run with this patched and see what happens. The machine can compile > the kernel through the night for testing this... If you do NOT 'make mrproper' and change only radeon/amdgpu stuff it should only take some minutes (seconds) on your system/CPU. > This seems to be the real core of the issue. We hear from you. ;-) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #52 from Richard Thier --- (In reply to Marek Olšák from comment #45) > The problem might be in the kernel. See function rs400_gpu_init. I think it > should call r300_gpu_init instead of r420_pipes_init. Aaaah Am I this blind? Now I see exactly this. Also in dmesg log I see RS400 being written out so yes I end up here and according to my own links this seem to be the problem that the rs400_gpu_init should not do the r420_pipes_init, because it is not r420 yet Now after investigating I think I should indeed end up here with the rs400_asic, but yes the 420 pipe setup is wrong - at least for my card. I will run with this patched and see what happens. The machine can compile the kernel through the night for testing this... This seems to be the real core of the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #51 from Richard Thier --- (In reply to cosiekvfj from comment #17) >*-display > description: VGA compatible controller > product: RC410M [Mobility Radeon Xpress 200M] > vendor: Advanced Micro Devices, Inc. [AMD/ATI] > physical id: 5 > bus info: pci@:01:05.0 > version: 00 > width: 32 bits > clock: 66MHz > capabilities: pm msi vga_controller bus_master cap_list rom > configuration: driver=radeon latency=66 mingnt=8 > resources: irq:17 memory:d000-dfff > ioport:9000(size=256) memory:c000-c000 memory:c-d Hi cosiekvfj! Can you attach what your dmesg output is? The whole output, but especially this part: radeon: 3 quad pipes, 1 z pipes initialized. Do you also get 3 quad pipes and 1 z pipes? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #50 from Richard Thier --- " Also there is this "RS400" asic listed in the above switch case and it is still an other candidate maybe but surely not the rs400_asic. " I mean my card should be surely not rs420_asic. The rs_400 I didn't look through yet. Now I am looking where the device family is being set as maybe that might indicate why I get a wrong value... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #49 from Richard Thier ---
Hmmm. There are a lot of FIXMEs in the kernel at this part saying things are
not pretty sure. I think I am running into an other code path I should be
taking, but if this was always like this then maybe "fixing" it will just cause
a whole lot of errors...
RC410 is said to use the "RAGE 8" architecture:
https://www.techpowerup.com/gpu-specs/ati-rc410.g757.
Looking up Rage8 it seems to be RV350 so the mesa side seems to be more right
about what category it puts my card into.
In this place I see a lot of asics (for example r300_asic and r420_asic):
drivers/gpu/drm/radeon/radeon_asic.c
All of these structs have their rxx_init functions set in the struct (basically
a vtable using structs and function pointers). I think maybe the wrong one is
used for my card.
For example RV410 is said to be r400 architecture card instead of "Rage8"
(RV350) architecture one here:
https://www.techpowerup.com/gpu-specs/ati-rv410.g9
It can very likely have happened that the because of the number itself they
classified my Mobility Radeon Xpress 200M as r400 while it is basically an
RV350 and having a marketing-affected naming scheme confusion...
Look at this function:
2306 /**
2307 * radeon_asic_init - register asic specific callbacks
2308 *
2309 * @rdev: radeon device pointer
2310 *
2311 * Registers the appropriate asic specific callbacks for each
2312 * chip family. Also sets other asics specific info like the number
2313 * of crtcs and the register aperture accessors (all asics).
2314 * Returns 0 for success.
2315 */
2316 int radeon_asic_init(struct radeon_device *rdev)
2317 { ...
This is the one that sets the asic and there is a big switch-case for setting
the "proper" one in the driver based on "rdev->family".
My RC410 is not directly named here:
case CHIP_R300:
case CHIP_R350:
case CHIP_RV350:
case CHIP_RV380:
if (rdev->flags & RADEON_IS_PCIE)
rdev->asic = _asic_pcie;
else
rdev->asic = _asic;
break;
case CHIP_R420:
case CHIP_R423:
case CHIP_RV410:
rdev->asic = _asic;
/* handle macs */
if (rdev->bios == NULL) {
rdev->asic->pm.get_engine_clock =
_legacy_get_engine_clock;
rdev->asic->pm.set_engine_clock =
_legacy_set_engine_clock;
rdev->asic->pm.get_memory_clock =
_legacy_get_memory_clock;
rdev->asic->pm.set_memory_clock = NULL;
rdev->asic->display.set_backlight_level =
_legacy_set_backlight_level;
}
break;
case CHIP_RS400:
case CHIP_RS480:
rdev->asic = _asic;
break;
case CHIP_RS600:
(there are other families mentioned here as well, but these are the ones that
might affect my case I think)
According to techpowerup.com saying that Xpress 200M is Rage8 architecture I
should also get an r300 asic and the same as the RV350:
https://www.techpowerup.com/gpu-specs/ati-rv350.g13
Also there is this "RS400" asic listed in the above switch case and it is still
an other candidate maybe but surely not the rs400_asic.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #48 from Richard Thier --- Btw I saw that mesa codes handle my RC410 as one having RV350 (is_rv350 is true), but unlike R400 family chip. I have no idea if that is right, but if the kernel part do differently than the userland part that is clearly wrong that is sure! I kind of have a feeling this card is closer to R300 family than R400, but these are the questions that I have problems answering myself :-( In any ways. I think the wrong rXX_start function is called and r300_start shoud have been called instead in my case originally... Now I am looking where to fix this as it seems like an easy patch after properly finding the issue source. Actually if this is the case I am only lucky that this manifests itself only in this subtle details because that means a whole minor family different code is running for my card and it takes only luck that it works... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #47 from Richard Thier ---
Created attachment 144552
--> https://bugs.freedesktop.org/attachment.cgi?id=144552=edit
grepping around init functions in kernel / drm
Hmmm... I see that this got printed out in dmesg:
[ 17.669902] [drm] radeon: 3 quad pipes, 1 z pipes initialized.
However here is an excerpt from the kernel function you mention:
static void r300_gpu_init(struct radeon_device *rdev)
{
uint32_t gb_tile_config, tmp;
if ((rdev->family == CHIP_R300 && rdev->pdev->device != 0x4144) ||
(rdev->family == CHIP_R350 && rdev->pdev->device != 0x4148)) {
/* r300,r350 */
rdev->num_gb_pipes = 2;
} else {
/* rv350,rv370,rv380,r300 AD, r350 AH */
rdev->num_gb_pipes = 1;
}
...
DRM_INFO("radeon: %d quad pipes, %d Z pipes initialized\n",
rdev->num_gb_pipes, rdev->num_z_pipes);
}
And it is pretty clear that the there is nothing that should change the number
between the log and the setup code! This kind of tells me that this function is
not called.
I see multiple "rXX_gpu_init" functions so maybe the corresponding one should
be called, but in my case not an r300 but the rs400 variant is called? See
attachment about me grepping around in kernel sources.
I mean.. maybe calling "rs400_gpu_init" is already bad and it should be instead
the r300_gpu_init here!
Also I can see there are multiple implementations for the r420_pipes_init, but
mostly for later cards so it kind of seems something is really off. Maybe
someone just saw "oh RC410? That is higher number than 400 so it is an rs400
card" and completely disconfigure this card for some reason??? I mean... I can
still sometimes grow unsure where this specific card belongs to "properly" so I
can imagine someone just thinking the above.
[prenex@prenex-laptop zen-kernel-5.0.17-lqx1]$ grep -R r420_pipes_init
drivers/gpu/*
drivers/gpu/drm/radeon/rs400.c: r420_pipes_init(rdev);
drivers/gpu/drm/radeon/rv515.o bináris fájl illeszkedik
drivers/gpu/drm/radeon/rs600.o bináris fájl illeszkedik
drivers/gpu/drm/radeon/r520.c: r420_pipes_init(rdev);
drivers/gpu/drm/radeon/radeon.o bináris fájl illeszkedik
drivers/gpu/drm/radeon/rs690.c: r420_pipes_init(rdev);
drivers/gpu/drm/radeon/r420.c:void r420_pipes_init(struct radeon_device *rdev)
drivers/gpu/drm/radeon/r420.c: r420_pipes_init(rdev);
drivers/gpu/drm/radeon/rs690.o bináris fájl illeszkedik
drivers/gpu/drm/radeon/r520.o bináris fájl illeszkedik
drivers/gpu/drm/radeon/radeon_asic.h:extern void r420_pipes_init(struct
radeon_device *rdev);
drivers/gpu/drm/radeon/rs600.c: r420_pipes_init(rdev);
drivers/gpu/drm/radeon/r420.o bináris fájl illeszkedik
drivers/gpu/drm/radeon/radeon.ko bináris fájl illeszkedik
drivers/gpu/drm/radeon/rs400.o bináris fájl illeszkedik
drivers/gpu/drm/radeon/rv515.c: r420_pipes_init(rdev);
I don't see it yet where the radeon driver decides which of the r*_gpu_init
function to call, but I am already grepping for it. If there is an easy to spot
error there I might be even able to patch it - or at least go further :-)
Oh I see now that I am grepping for the wrong function as likely "r300_startup"
is the one that calls the r300_gpu_init (and likely others call the same in the
similar pattern) so I must search for this startup function instead.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #46 from Richard Thier --- (In reply to Marek Olšák from comment #45) > The problem might be in the kernel. See function rs400_gpu_init. I think it > should call r300_gpu_init instead of r420_pipes_init. I will put some logging there to be sure because as I see the codebase on the mesa side I got the feeling that "rs400" is basically r420+ and even RC410 and such belong to r300 so if this is consistent and good, then the kernel code there can be too. Except if it is really called on my machine as then that might be really-really a mistake then. I will look at it later. Still testing a bit first if this way everything works properly - also I have less time because there is good weather to work on wine field and later there will be rainy weather to work endlessly on these. ;-) > RC410 most likely has only 1 pipe. > 3 pipes would be for a discrete GPU that isn't small. Thanks for this guess! I really had no experience to even guess this. Everything points in this direction though so I think this is the case. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #45 from Marek Olšák --- The problem might be in the kernel. See function rs400_gpu_init. I think it should call r300_gpu_init instead of r420_pipes_init. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #44 from Marek Olšák --- RC410 most likely has only 1 pipe. 3 pipes would be for a discrete GPU that isn't small. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #43 from Marek Olšák --- You can try to compare your num_gb_pipes with somebody else who has the same GPU. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #42 from Richard Thier ---
(In reply to Marek Olšák from comment #40)
> I'm afraid nobody remembers anymore how HyperZ works on r300. I can answer
> basic questions if you have any.
Hi!
Currently I have added this to radeon_drm_winsys.c:
385 if (ws->gen == DRV_R300) {
386 if (!radeon_get_drm_value(ws->fd, RADEON_INFO_NUM_GB_PIPES,
387 "GB pipe count",
388 >info.r300_num_gb_pipes))
389 return false;
390 + // FIXME: only works for my own setup (prenex):
391 + ws->info.r300_num_gb_pipes=1;
Now I have no problems so far. It can be that HyperZ code is just good as-is,
but for some resoun the radeon_get_drm_value returns a bad gb_pipes number.
Currently testing with this a bit more throughly before moving further, but
everything seems to work so far, just this is not a proper fix.
Some questions I can have:
1.) Is there any way to ensure how many pipes a card has? One pipeline seems to
be really few for a GPU, but this is a mobile integrated card.
2.) Can the other indicated pipes be existing on my card but turned off for
some reason?
3.) radeon_get_drm_value - is this in the kernel source tree? I will have a
look later on the code behind it.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #41 from Dieter Nützel --- (In reply to Marek Olšák from comment #40) > I'm afraid nobody remembers anymore how HyperZ works on r300. I can answer > basic questions if you have any. Hello Marek! Thanks for your offer, I know you were around... I've found some hints for Richard under #note_14 Your Mesa git commit #12dcbd5954676ee32604d82cacbf9a4259967e13 r300g: enable Hyper-Z by default on r500 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #40 from Marek Olšák --- I'm afraid nobody remembers anymore how HyperZ works on r300. I can answer basic questions if you have any. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #39 from Dieter Nützel --- Oh and have a look, here: Feature Matrix for Free Radeon Drivers https://www.x.org/wiki/RadeonFeature/ r300 have some points open...;-) https://www.x.org/wiki/RadeonFeature/#note_14 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Dieter Nützel changed: What|Removed |Added CC||mar...@gmail.com, ||mic...@daenzer.net --- Comment #38 from Dieter Nützel --- (In reply to Richard Thier from comment #37) > (In reply to Dieter Nützel from comment #35) > > Hello Richard, > > > > very NICE progress! > > > > Maybe you can run 'glmark2' with/without HyperZ. > > Good idea. > > Can you test if HyperZ works for you without any changes? Sorry, I'haven't any system for r300 (PCI/AGP) handy. Latest here HD 4650, RV730 AGP (1 GB !), r600 (see older bug reports...;-) But not booted for nearly 2 years... Maybe I have an older r300 one (yep, 9550), but I have to dig in the basement for it, if you need. > The progress I > made basically only works on my machine but above cosiekvfj seems to have no > issues despite having the same card. You made GREAT progress! We have to ping Michel Dänzer and Marek Olšák for your open questions. (see CC list) > Actually if the gb_pipes number is wrong then the error is not even in the > HyperZ code, but in the code that returns the wrong value from drm - that > HyperZ code is just using. > > Oh and keep in mind that I have no HiZ RAM! So if I measure speed gains > others might measure a higher gain if they have HiZ RAM too as I think this > way I have no hierarchical Z-buffer at all - when bigger tiles store min or > max z values of theirs and first they are compared not pixels - but I have > this compressed Z-buffer or zmask_ram - latter which is a lossless > compression of the zbuffer. I read that they use tricks like storing the > one-two triangles directions basically for whole tiles to save some bandwith > and/or indicate if a tile is compressed or not at all. > > This latter seems to help memory bandwith in case the triangles are bigger > than the tiles (typically: walls in a game maybe?). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #37 from Richard Thier --- (In reply to Dieter Nützel from comment #35) > Hello Richard, > > very NICE progress! > > Maybe you can run 'glmark2' with/without HyperZ. Good idea. Can you test if HyperZ works for you without any changes? The progress I made basically only works on my machine but above cosiekvfj seems to have no issues despite having the same card. Actually if the gb_pipes number is wrong then the error is not even in the HyperZ code, but in the code that returns the wrong value from drm - that HyperZ code is just using. Oh and keep in mind that I have no HiZ RAM! So if I measure speed gains others might measure a higher gain if they have HiZ RAM too as I think this way I have no hierarchical Z-buffer at all - when bigger tiles store min or max z values of theirs and first they are compared not pixels - but I have this compressed Z-buffer or zmask_ram - latter which is a lossless compression of the zbuffer. I read that they use tricks like storing the one-two triangles directions basically for whole tiles to save some bandwith and/or indicate if a tile is compressed or not at all. This latter seems to help memory bandwith in case the triangles are bigger than the tiles (typically: walls in a game maybe?). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #36 from Richard Thier ---
Okay it seems pipes=1 is working on my machine.
diff --git a/src/gallium/drivers/r300/r300_texture_desc.c
b/src/gallium/drivers/r300/r300_texture_desc.c
index 77d272bfb6b..029b28570d7 100644
--- a/src/gallium/drivers/r300/r300_texture_desc.c
+++ b/src/gallium/drivers/r300/r300_texture_desc.c
@@ -358,6 +358,9 @@ static void r300_setup_hyperz_properties(struct r300_screen
*screen,
pipes = screen->info.r300_num_z_pipes;
} else {
pipes = screen->info.r300_num_gb_pipes;
+ /* FIXME: Quickfix only for Mobility Radeon Xpress 200M in asus
laptop! */
+pipes = 2; // Half the screen is bad for me
+pipes = 1; // Whole screen is ok for me
}
for (i = 0; i <= tex->b.b.last_level; i++) {
I do not even dare uploading this patch as it likely only works on my specific
machine! The know-how seems to be worthy of knowing though so in case anyone
see something like this, they can try something similar until there is a proper
fix.
317 /* The tile size of 1 DWORD in ZMASK RAM is:
318 *
319 * GPUPipes4x4 mode 8x8 mode
320 * --
321 * R580 4P/1Z32x32 64x64
322 * RV570 3P/1Z48x16 96x32
323 * RV530 1P/2Z32x16 64x32
324 *1P/1Z16x16 32x32
325 */
326 static unsigned zmask_blocks_x_per_dw[4] = {4, 8, 12, 8};
327 static unsigned zmask_blocks_y_per_dw[4] = {4, 4, 4, 8};
I should have thought that pipes=1 is for me. As you can see here, there are
hardcoded values for X and Y block counts. Originally drm reports pipes=3 for
my card so I end up using the third column in this table: 12*4 blocks.
Now remembering I had to half both of them earlier using the hacky patch (6*2)
it was sure that "pipes=2" would not work still, because 4*8 = 32 is still much
more than 6*2=12 I provided. Of course 4*4=16 so now I see my earlier hack was
a bit miscalculated.
Also now I see exactly why 1/3 of the screen was only "working": because 12/4 =
3 and 4/4=1. You can clearly see this from the table!!! Wow!
I see that "r300_num_gb_pipes" is used at some of the other places:
src/gallium/drivers/r300/r300_query.c
src/gallium/drivers/r300/r300_emit.c (also for some queries)
src/gallium/drivers/r300/r300_context.c (only fprintf-ing for debugging)
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c (this where the drm query is)
I do not really know what kind of "queries" are these, but I might go and
change code so that winsys returns gb_pipes=1 itself without hacks at other
places and see if there are other glitches (a bit prolonged testing).
Who knows, maybe things actually get less glitchy if this query stuff is really
used and the value was bad before!
Then if I see that I really only have one pipeline, then maybe I should look at
the other side of this drm call to see why it returns this value and not else.
PS.: One other thing that I do not know is if pipes can exist maybe but can be
turned off or something? But I really have no idea about that.
PS.: I also grow to understand the logic why the smaller values here actually
make more to be properly rendered on screen! Because if there are two or three
pipes for example, you clear things similarly to this pattern:
01012323 etc (I saw them in docs or source comments). So if there would be
two pipes, you can z-delete two blocks at the same time etc. it is only simple
maths to see the smaller values are better here then.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #35 from Dieter Nützel --- Hello Richard, very NICE progress! Maybe you can run 'glmark2' with/without HyperZ. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #34 from Richard Thier --- Created attachment 144549 --> https://bugs.freedesktop.org/attachment.cgi?id=144549=edit Proof screenshot that it works now Added screenshot of HyperZ "just working" with the quickfix for me. I think it only applies to my machine so far but this might be the good direction. I have first started with RADEON_HYPERZ=0 and got 350 FPS then started with the flag and still have the picture while having 440 FPS. So I both have picture and speedup. What is weird is why it was working yesterday without me touching these parts of the code... I think some stack change got luck and got stuck in the good state for some reason... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #33 from Richard Thier ---
Created attachment 144548
--> https://bugs.freedesktop.org/attachment.cgi?id=144548=edit
Working hack / quickfix
Pretty interesting but I just tried to change the "most logical" part of
r300_texture_desc.c and now it works - see quickfix patch.
I will tell you all what was my approach. I just started to ignore all my
previous attempts and go for a more "mágus" approach. That is is like "bogus"
approach, but "mágus" approach involves faith and magix haha.
The goal was to find a way to make the still non-erronous area of the image
grow. Just by trying around the code and possibly breaking law of the rules
(Judas Priest song should play in the background while readers read this for
best effect).
So this file seemed to be the good candidate for "breaking the law" and just
"mágus-approach" trying: r300_texture_desc.c
Then there was this part:
376 /* Get the ZMASK buffer size in dwords. */
377 zcomp_numdw = r300_pixels_to_dwords(stride, height,
378 zmask_blocks_x_per_dw[pipes-1] * zcompsize,
379 zmask_blocks_y_per_dw[pipes-1] * zcompsize);
380
381 /* Check whether we have enough ZMASK memory. */
382 if (util_format_get_blocksizebits(tex->b.b.format) == 32 &&
383 zcomp_numdw <= screen->caps.zmask_ram * pipes) {
384 tex->tex.zmask_dwords[i] = zcomp_numdw;
385 tex->tex.zcomp8x8[i] = zcompsize == 8;
386
387 tex->tex.zmask_stride_in_pixels[i] =
388util_align_npot(stride, zmask_blocks_x_per_dw[pipes-1] *
zcompsize);
The "zcomp_numdw" seems to be "the number of dwords" in the zmask_ram - and the
zmask ram is the compressed z-buffer itself. This "tex->tex.zmask_dwords[i]"
has multiple element because of the mip level. Of course I think only the first
element ever exists for zbuffer as I haven't seen mipmapped z ever just telling
you why there is indexing.
In short I saw earlier that this "zmask_dwords" get used later on even when
emitting but also at other places like in r300_blit.c for example. It is used
pretty much so this seemed to be the thing to change in my planned "mágus" way
;-)
I went and first doubled the value like this (please mind the "*2"):
376 /* Get the ZMASK buffer size in dwords. */
377 zcomp_numdw = r300_pixels_to_dwords(stride, height,
378 zmask_blocks_x_per_dw[pipes-1] * zcompsize*2,
379 zmask_blocks_y_per_dw[pipes-1] * zcompsize*2);
After that change the "still uneffected" area of the screen shrink roughly to
its 1/4th so I figured instead of multiplying the values I should divide them
by two (just guessing):
376 /* Get the ZMASK buffer size in dwords. */
377 zcomp_numdw = r300_pixels_to_dwords(stride, height,
378 zmask_blocks_x_per_dw[pipes-1] * zcompsize/2,
379 zmask_blocks_y_per_dw[pipes-1] * zcompsize/2);
And indeed now the whole screen is good and performance is fast too.
It is a hack however - just pure magic so far, but it seems that somehow this
value might be the one that can fix the problem.
My idea is that maybe that value of "pipes" is wrong???
This is where that variable is set:
357 if (screen->caps.family == CHIP_RV530) {
358 pipes = screen->info.r300_num_z_pipes;
359 } else {
360 pipes = screen->info.r300_num_gb_pipes;
361 }
Also because my card is not CHIP_RV530 the value is the
screen->info.r300_num_gb_pipes
This is set in: radeon_drm_winsys.c / do_winsys_init(...)
385 if (ws->gen == DRV_R300) {
386 if (!radeon_get_drm_value(ws->fd, RADEON_INFO_NUM_GB_PIPES,
387 "GB pipe count",
388 >info.r300_num_gb_pipes))
389 return false;
I have no idea where this value comes from. Would need to see the other side in
the kernel modules I guess or some other places. If this is wrong it might
maybe cause other problems for me that I am not aware of while things still
generally work most of the time?
Also just a note for myself - the RC410 is R300 class / kind card not an R400
it seems - but I saw places where is_rv350 returns true, so those things seem
to be on in the driver for me at least:
205 case CHIP_R300:
206 case CHIP_R350:
207 case CHIP_RV350:
208 case CHIP_RV370:
209 case CHIP_RV380:
210 case CHIP_RS400:
211 case CHIP_RC410:
212 case CHIP_RS480:
213 ws->info.chip_class = R300;
So gb_pipes is 3 for my case, but maybe it should be a different value and this
is set badly for some reason. Of course this would explain the problem better.
One more thing: I build mesa to my own prefix and after this hacky quickfix
patch things immediately started working - even if I run glxgears with HYPERZ
from an other terminal
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #32 from Richard Thier --- If my card has no "hiz_ram" what that means? Can anyone explain if I am right? This is what I suspect so far: - Zcompression I get still, because the card has zmask_ram - No hierarchical Z (hiz) at all because there is no hiz_ram I do not see from the docs if there are specialties if enabing zmask_ram only, but not enabling hiz. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #31 from Richard Thier --- Created attachment 144545 --> https://bugs.freedesktop.org/attachment.cgi?id=144545=edit Really no cmask ram it seems I have faked to have hiz ram and cmask ram just to see what happens. When I am turning on MSAA now I get this glitches from the shared screenshot so I guess it is right that my card is just not having CMASK_RAM. 122 case CHIP_RS480: 123 caps->zmask_ram = RV3xx_ZMASK_SIZE; 124 caps->has_cmask = TRUE; /* guessed because there is also HiZ */ 125 caps->hiz_ram = R300_HIZ_LIMIT; 126 break; hiz_ram faking seems to have no effect whatsoever. I have also tried this hack - but it did not help: diff --git a/src/gallium/drivers/r300/r300_emit.c b/src/gallium/drivers/r300/r300_emit.c index 80c959b95d0..48fafecfdda 100644 --- a/src/gallium/drivers/r300/r300_emit.c +++ b/src/gallium/drivers/r300/r300_emit.c @@ -1224,6 +1224,10 @@ void r300_emit_hiz_clear(struct r300_context *r300, unsigned size, void *state) tex = r300_resource(fb->zsbuf->texture); BEGIN_CS(size); +// FIXME: Remove this hack! +OUT_CS_REG(R300_ZB_ZCACHE_CTLSTAT, +R300_ZB_ZCACHE_CTLSTAT_ZC_FLUSH_FLUSH_AND_FREE | +R300_ZB_ZCACHE_CTLSTAT_ZC_FREE_FREE); OUT_CS_PKT3(R300_PACKET3_3D_CLEAR_HIZ, 2); OUT_CS(0); OUT_CS(tex->tex.hiz_dwords[fb->zsbuf->u.tex.level]); @@ -1246,6 +1250,9 @@ void r300_emit_zmask_clear(struct r300_context *r300, unsigned size, void *state tex = r300_resource(fb->zsbuf->texture); BEGIN_CS(size); +OUT_CS_REG(R300_ZB_ZCACHE_CTLSTAT, +R300_ZB_ZCACHE_CTLSTAT_ZC_FLUSH_FLUSH_AND_FREE | +R300_ZB_ZCACHE_CTLSTAT_ZC_FREE_FREE); OUT_CS_PKT3(R300_PACKET3_3D_CLEAR_ZMASK, 2); OUT_CS(0); OUT_CS(tex->tex.zmask_dwords[fb->zsbuf->u.tex.level]); -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #30 from Richard Thier --- It seems it can be normal, but then my understanding of hyperZ was a bit off then. I will try adding hiz ram for it just to see what happens :-) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #29 from Richard Thier ---
Okay this is weird for me:
/* src/gallium/drivers/r300/r300_texture_desc.c */
399 /* Get the HIZ buffer size in dwords. */
400 hiz_numdw = (stride * height) / (8*8 * pipes);
401
402 /* Check whether we have enough HIZ memory. */
403 if (hiz_numdw <= screen->caps.hiz_ram * pipes) {
404 tex->tex.hiz_dwords[i] = hiz_numdw;
405 tex->tex.hiz_stride_in_pixels[i] = stride;
406 } else {
407 tex->tex.hiz_dwords[i] = 0;
408 tex->tex.hiz_stride_in_pixels[i] = 0;
409 }
(gdb) p hiz_numdw
$35 = 1128
(gdb) p screen->caps.hiz_ram
$36 = 0
(gdb)
(!) Is it normal to have zero hiz_ram on this
card???
Btw:
info.r300_num_z_pipes == 1
info.r300_num_gb_pipes == 3 (this is in the pipes var)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #28 from Richard Thier ---
I still see the glitches with the following changes:
@@ -364,11 +369,21 @@ static void r300_clear(struct pipe_context* pipe,
/* Clear. */
if (buffers) {
/* Clear using the blitter. */
+
+/* FIXME: Twoline HACKZ TO SAVE FLAGS THAT blitter_clear clears */
+bool tmp_zmask_clear_dirty = r300->zmask_clear.dirty;
+ bool tmp_hiz_clear_dirty = r300->hiz_clear.dirty;
+
r300_blitter_begin(r300, R300_CLEAR);
util_blitter_clear(r300->blitter, width, height, 1,
buffers, color, depth, stencil);
+ /* FIXME: two lines of hack! */
+ r300->zmask_clear.dirty = tmp_zmask_clear_dirty;
+ r300->hiz_clear.dirty = tmp_hiz_clear_dirty;
+
r300_blitter_end(r300);
-} else if (r300->zmask_clear.dirty ||
+/* TIPP: here maybe not else if, just an if should be present??? */
+} /*else*/ if (r300->zmask_clear.dirty ||
r300->hiz_clear.dirty ||
r300->cmask_clear.dirty) {
Even though we are now entering the things after this if and go where the zram
clear emit is. Maybe this is not the problem...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Richard Thier changed: What|Removed |Added Priority|low |medium -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #27 from Richard Thier ---
This is also always happening:
434 /* Enable fastfill and/or hiz.
435 *
436 * If we cleared zmask/hiz, it's in use now. The Hyper-Z state update
437 * looks if zmask/hiz is in use and programs hardware accordingly. */
438 if (r300->zmask_in_use || r300->hiz_in_use) {
439 r300_mark_atom_dirty(r300, >hyperz_state);
440 }
So we do get into the body of the if as zmasn_in_use is true here.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #26 from Richard Thier ---
Okay it is still bad now despite I have compiled with "-O0" flags actually...
To be honest I have no idea actually why it started working last time.
Also now that I step with the debugger I see that a lot of code paths
that I imagine should be taken are never ever taken.
Also when going randomly in the code with gdb I have found the following
things. I just want to document my findings so far with gdb breakpoints in the
driver. These are maybe not general for everyone, but this is what happens on
my very machine and card when debugging r300 code with gdb...
WHAT HAPPENS IN r300_blit.c
===
You can roughly follow this stuff here:
https://github.com/anholt/mesa/blob/master/src/gallium/drivers/r300/r300_blit.c
0.) Setting of zmask_clear=1 and hiz_clear=0 always happen
--
262 /* Use fast Z clear.
263 * The zbuffer must be in micro-tiled mode, otherwise it locks up. */
264 if (buffers & PIPE_CLEAR_DEPTHSTENCIL) {
265 boolean zmask_clear, hiz_clear;
266
267 /* If both depth and stencil are present, they must be cleared
together. */
268 if (fb->zsbuf->texture->format == PIPE_FORMAT_S8_UINT_Z24_UNORM
&&
269 (buffers & PIPE_CLEAR_DEPTHSTENCIL) !=
PIPE_CLEAR_DEPTHSTENCIL) {
270 zmask_clear = FALSE;
271 hiz_clear = FALSE;
272 } else { /* ALWAYS HAPPENS: */
273 zmask_clear = r300_fast_zclear_allowed(r300, buffers);
274 hiz_clear = r300_hiz_clear_allowed(r300);
275 /* FIXME: only for testing! */
276 /*zmask_clear = FALSE;*/
277 /*zmask_clear = TRUE; // - this alone looks bad, bothfalse
look good, zmaks_clear only false hiz_clear untouched is good */
278 /*hiz_clear = FALSE;*/
279 /*hiz_clear = TRUE; // enabling this and falsing zmask_clear
shows picture but FPS is lower in glxgears...*/
We always go where I marked it with "/* ALWAYS HAPPENS */".
r300_fast_zclear_allowed(r300, buffers) return 1
r300_hiz_clear_allowed(r300) returns 0
So:
zmask_clear == 1
hiz_clear == 0
ALWAYS. As I understand the hiz_clear is the thing that clears the
"hierarchical Z" buffer and I suspect this should be returning true instead.
The other for zmask clearn is the one that clears the compessed z-buffer. I had
a bit of a hard time to figure out what these mean, but using the r5xx docs
(despite this card is r300) helped a lot. So zmask is a lossless compressed
z-buffer ram and hiz ram seem to be on the higher hiearchy level.
I have checked what is the body of the latter:
return
300_resource(fb->zsbuf->texture)->tex.hiz_dwords[fb->zsbuf->u.tex.level] != 0;
^^and this body never returns true for some reason. I think this should be
nonzero when HyperZ is properly going on isn't it? I am just running glxgears
and nothing fancy.
1.) "Enabling" HyperZ seem to happen properly
-
282 /* If we need Hyper-Z. */
283 if (zmask_clear || hiz_clear) {
284 /* Try to obtain the access to Hyper-Z buffers if we don't
have one. */
285 if (!r300->hyperz_enabled &&
286 (r300->screen->caps.is_r500 ||
debug_get_option_hyperz())) {
287 r300->hyperz_enabled =
288 r300->rws->cs_request_feature(r300->cs,
289
RADEON_FID_R300_HYPERZ_ACCESS,
290 TRUE);
291 if (r300->hyperz_enabled) {
292/* Need to emit HyperZ buffer regs for the first time.
*/
293r300_mark_fb_state_dirty(r300,
R300_CHANGED_HYPERZ_FLAG);
294 }
295 }
On the first run we get into the cs_request_feature stuff and then the
r300_mark_fb_state_dirty function properly. hiz_clear is never true here, but
the zmask_clear boolean is - see above. The debug_get_option_hyperz() is the
cause why this happens as that is the one that checks the environment variable.
297 /* Setup Hyper-Z clears. */
298 if (r300->hyperz_enabled) {
299 if (zmask_clear) {
300 hyperz_dcv = hyperz->zb_depthclearvalue =
301 r300_depth_clear_value(fb->zsbuf->format, depth,
stencil);
302
303 r300_mark_atom_dirty(r300, >zmask_clear);
304 r300_mark_atom_dirty(r300, >gpu_flush);
305 buffers &= ~PIPE_CLEAR_DEPTHSTENCIL;
306 }
307
308 if (hiz_clear) {
309 r300->hiz_clear_value = r300_hiz_clear_value(depth);
310 r300_mark_atom_dirty(r300, >hiz_clear);
311
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Richard Thier changed: What|Removed |Added Severity|minor |normal Priority|lowest |low -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #25 from Richard Thier --- Pfff it is bad once again now and I have no idea why... maybe a real heisenbug because of some state :-( Also turning off the machine or rebooting does not seem to help despite I went back to the "-O2" build... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #24 from Richard Thier --- Hmmm... With -O3 I see the same kind of issue. It seems it is there when highest optimization is on maybe? I will build -O2 once again without a restart just to see. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Richard Thier changed: What|Removed |Added Severity|normal |minor Priority|medium |lowest -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #23 from Richard Thier --- Or can it be that literally I had a short term hardware error in my card because of running in this hot summer for very long periods. I could be ram corruption too that just got solved now for some reason. Also I can image zram and hiz maybe seperate small static rams that were not used for years so it had to get some warmup time - quite the opposite of the overuse? In any ways. The performance is sometime a bit better, sometimes measurably better and now I do not see any glitches. Weird. I think I make this bug to be a "minor" one as maybe it is not really a real bug? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #22 from Richard Thier --- Created attachment 144532 --> https://bugs.freedesktop.org/attachment.cgi?id=144532=edit should not affect anything patch Interestingly now I am running with this patch, but I never saw this code path taken ever so it should not count. Also I have compiled with this setup and it works still: meson configure build/ -Dc_args="-O2 -Ofast" -Dcpp_args="-O2 -Ofast" -Dc_link_args="-O2 -Ofast" -Dcpp_link_args="-O2 -Ofast" I have yet to try with -O3 so far now, but it more and more looks this is just some kind of rare heisenbug. When it is not happening I cannot even make it work.. Also now that the bug only seem to appear very rarely it is much harder to debug and I think its impact is much smaller too... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #21 from cosiek...@o2.pl --- No wait. That reminds me of this weird behavior I had in https://bugs.freedesktop.org/show_bug.cgi?id=101382 17.1.2-1 crash(different) 17.1.1-1 crash(different) 17.1.0-1 crash(different) 17.0.5-1 working 17.0.4-2 working 17.0.4-1 crash 17.0.3-2 working 17.0.3-1 crash 17.0.2-2 working 17.0.2-1 crash 17.0.1-2 crash 17.0.1-1 crash 17.0.0-3 crash 17.0.0-2 crash 17.0.0-1 crash 13.0.4-2 crash Seemingly without any changes to r300 code… -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #20 from cosiek...@o2.pl --- >I have less and less of an idea when this thing happens. My first thought was maybe compositor or 64 vs 32 bit os. I'm using xfwm with compositing turned off. I also changed the CPU in this laptop ;) and I'm using 64 bit os. *-cpu description: CPU product: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz vendor: Intel Corp. physical id: 4 bus info: cpu@0 slot: U23 size: 1666MHz capacity: 1667MHz width: 64 bits clock: 100MHz capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti dtherm cpufreq But after you told us that glxgears "magically" works sometimes for you then I have no idea. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #19 from Richard Thier --- Btw the code paths for my logs are always the same - both when wrong and good I have no idea... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #18 from Richard Thier --- Weird. That is exactly the same card as mine... I have less and less of an idea when this thing happens. I will try building with various optimization fals but it might be also that the card can get stick in a state where hiz not working anymore but a real turnoff-turnon helped... I am less and less sure what triggers the bad behaviour. Now it is good atmy machine too. I will see if i can build with -O2 and fast math and still see it working -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #17 from cosiek...@o2.pl --- *-display description: VGA compatible controller product: RC410M [Mobility Radeon Xpress 200M] vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 5 bus info: pci@:01:05.0 version: 00 width: 32 bits clock: 66MHz capabilities: pm msi vga_controller bus_master cap_list rom configuration: driver=radeon latency=66 mingnt=8 resources: irq:17 memory:d000-dfff ioport:9000(size=256) memory:c000-c000 memory:c-d -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #16 from Richard Thier --- Btw I now have no problems at all... This is weird... all I did was to remove my printfs so that code is actually stock mesa and I both see the speed gain and there is no problems whatsoever... But I rebooted and started glxgears right away with HYPERZ enabled and no other programs ever. I could then start anything: browser, tuxracer, ... I have tried a shutdown of my machine, then start glxgears without HYPERZ and then start with and it still worked... But now I am compiling with "-O0" as I thought it is a good idea if I plan to use gdb. I am still not sure what fixes it: is it just the "-O0" or me not starting the browser first but glxgears... TL;DR: If you see this, there might ba a quick hack to completely turn off the machine and turn it on maybe and not start anything that uses the GPU just the 3D app that you want to have HYPERZ should maybe start first - or the workaround is to compile without any optimization maybe... These are the two things I did and now magically "it just works"... I have no idea... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #15 from Richard Thier --- (In reply to cosiekvfj from comment #14) > Created attachment 144524 [details] > bigger glxgears window > > >Is HyperZ just good without any changes to stock mesa? > yes, mesa is from manjaro repo, and I think that it's the same build as in > arch repo. > > >Your card seems to be also reported as RC410 like mine, but you have > >much-much more FPS for some reason. > It's because window size of glxgears ;) We could test that if you want. But > we need to agree on window size ;) > > >Is this also a laptop? > Yes. Can you share lspci and lshw output? > I also tried to resize window to try to get some artifacts. Apart from some > flickering during resizing, image was good. Flickering was also present > without HyperZ. Resize only helped against the problem in my case so I would not expect things go flicker when resizing anyways, just that in my case it was "at least" flickering instead of not being visible at all properly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #14 from cosiek...@o2.pl --- Created attachment 144524 --> https://bugs.freedesktop.org/attachment.cgi?id=144524=edit bigger glxgears window >Is HyperZ just good without any changes to stock mesa? yes, mesa is from manjaro repo, and I think that it's the same build as in arch repo. >Your card seems to be also reported as RC410 like mine, but you have much-much >more FPS for some reason. It's because window size of glxgears ;) We could test that if you want. But we need to agree on window size ;) >Is this also a laptop? Yes. I also tried to resize window to try to get some artifacts. Apart from some flickering during resizing, image was good. Flickering was also present without HyperZ. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #13 from cosiek...@o2.pl --- 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RC410M [Mobility Radeon Xpress 200M] (prog-if 00 [VGA controller]) Subsystem: Packard Bell B.V. RC410M [Mobility Radeon Xpress 200M] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #12 from Richard Thier --- Hi Cosiek! What card is that (lspci output maybe)? Is HyperZ just good without any changes to stock mesa? Your card seems to be also reported as RC410 like mine, but you have much-much more FPS for some reason. Is this also a laptop? > I just want to warn you that there may be some more bugs in r300 driver. I also know about one more that affects specifically the "Total War" games. Both Rome: Total War 1 and Medieval: Total War 2. I see very bad "tiling" but from the size of the bad tiles I kind of think it is likely maybe some kind of texture format or something similar that goes wrong. I haven't even started the analysis because better do one thing at a time... It is good that you point me towards this issue too as who knows if this is maybe not the one affecting the game maybe? Also I have found out only now how "easy" is to gdb the userland driver! All I need to do is to know proper function names and I can breakpoint them easily after answering yes to gdb when it asks me that it does not find the function yet but if it should set breakpoint when the shared object is loaded... Before this I just used printfs and stuff... Both have use cases of course. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #11 from cosiek...@o2.pl --- Created attachment 144523 --> https://bugs.freedesktop.org/attachment.cgi?id=144523=edit good HyperZ glxgears Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org R300 Project (0x1002) Device: ATI RC410 (0x5a62) Version: 19.0.6 Accelerated: yes Video memory: 128MB Unified memory: no Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL vendor string: X.Org R300 Project OpenGL renderer string: ATI RC410 OpenGL version string: 2.1 Mesa 19.0.6 OpenGL shading language version string: 1.20 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #10 from cosiek...@o2.pl --- >Was it looking similar? Was it solved for your case? I didn't report that bug. Someone just wrote in that thread that HyperZ was not enabled due to lack of testing, so I ran some piglid tests. :) I just want to warn you that there may be some more bugs in r300 driver. For example: https://bugs.freedesktop.org/show_bug.cgi?id=98869 There was workaround put in place to resolve this bug (So no proper fix for underlying issue. See this mailing list conversation: https://lists.freedesktop.org/archives/mesa-dev/2017-February/143980.html). But later I found out that after some upgrades game started crashing. But never really figured out why. And didn't test it after that as I already finished that game :) https://bugs.freedesktop.org/show_bug.cgi?id=101382 I'm glad for your r300 work! :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #9 from Richard Thier ---
So these does not seem to happen at any time:
/* Emit clear packets. */
r300_emit_gpu_flush(r300, r300->gpu_flush.size, r300->gpu_flush.state);
r300->gpu_flush.dirty = FALSE;
if (r300->zmask_clear.dirty) {
fprintf(stderr, "KUL-AKVA\n");
r300_emit_zmask_clear(r300, r300->zmask_clear.size,
r300->zmask_clear.state);
r300->zmask_clear.dirty = FALSE;
}
if (r300->hiz_clear.dirty) {
fprintf(stderr, "KUL-AKVA2\n");
r300_emit_hiz_clear(r300, r300->hiz_clear.size,
r300->hiz_clear.state);
r300->hiz_clear.dirty = FALSE;
}
if (r300->cmask_clear.dirty) {
r300_emit_cmask_clear(r300, r300->cmask_clear.size,
r300->cmask_clear.state);
r300->cmask_clear.dirty = FALSE;
}
At least not with glxgears. But I kind of get the impression that the intention
of the code is to end up here as earlier we set things as dirty:
/* Setup Hyper-Z clears. */
if (r300->hyperz_enabled) {
if (zmask_clear) {
hyperz_dcv = hyperz->zb_depthclearvalue =
r300_depth_clear_value(fb->zsbuf->format, depth,
stencil);
r300_mark_atom_dirty(r300, >zmask_clear);
r300_mark_atom_dirty(r300, >gpu_flush);
buffers &= ~PIPE_CLEAR_DEPTHSTENCIL;
/* FIXME: REMOVE KUL* LOGS: */
fprintf(stderr, "KUL-A\n");
}
if (hiz_clear) {
r300->hiz_clear_value = r300_hiz_clear_value(depth);
r300_mark_atom_dirty(r300, >hiz_clear);
r300_mark_atom_dirty(r300, >gpu_flush);
}
r300->num_z_clears++;
}
Looking at mark_atom_dirty it seems to set the flag. I do not know who deletes
it but it got deleted. Also I have printed what is the value of "buffers" where
we enter the "KUL-C" code path (according to my log scheme) and the value is
buffers=4 which is the first (0th) color buffer. It is not some new kind, but
above this check I see only one place where this could get zeroed and maybe
that is not happening for this card but for others it does.
What bugs me is that the dirtyness of zmask_clear and hiz_clear also go away
somewhere, but I am too tired to see where. Just wanted to write down all the
stuff so far and at least provide the logs and insights.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #8 from Richard Thier --- I think I see a bug happening here and we are not emitting the relevant things. A bit tired now for the night... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #7 from Richard Thier --- Created attachment 144515 --> https://bugs.freedesktop.org/attachment.cgi?id=144515=edit Log output for "added logging" patch As you can see the "KUL-D" and the "KULAKVA-n" log messages never gets printed out but the KUL-A gets to be and even "KUL-C" now for some reason. I expect we should have emitted the flush, zmask clear and/or hiz clear, but it seems we are not ever getting at that code path. I am wondering what might be the value of the "buffer" variable here as all I know is that it is not empty, but I think the code is written in the way that it expects that it is and only do the emit operations if it is empty. Maybe a new kind of buffer was added and code did not changed or who knows... then it can be a regression actually... but I have no idea why it might work for anyone then... But look at the log and the patch. For me it is weird what is happening. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #6 from Richard Thier --- Created attachment 144514 --> https://bugs.freedesktop.org/attachment.cgi?id=144514=edit Added logging - magically works but slow from logging! This is what I am running with now. There are no other changes and not despite I gave back the commented-out earlier code part things do work, despite I have only added comments p maybe it is working because of some weird waiting that the logs give me... I will attach the log that is generated, because things do not go in the direction I was hoping for as I expected other code paths to happen when the RADEON_HYPERZ=1 is on. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #5 from Richard Thier --- Hi! Was it looking similar? Was it solved for your case? Btw I just started to have insights on what the hardware does, but might need to work a bit in the wine field because of the good weather so if I am off a bit for a day or two it will not mean I am stuck with the problem. I think I will add extra logs soon to have a grasp about what is going on. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #4 from cosiek...@o2.pl --- Hello you all! Couple of years ago I did tests HyperZ https://bugs.freedesktop.org/show_bug.cgi?id=37724 Maybe you will find this link useful! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #3 from Richard Thier --- H... I must have made a measurement error as looking at the code the small patch of mine cannot be slower than before it when not using HYPERZ... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #2 from Richard Thier --- Created attachment 144512 --> https://bugs.freedesktop.org/attachment.cgi?id=144512=edit 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 buffers. 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: 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 see. Interestingly there is a performance drop now - I mean a drop from an unchanged 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 flag 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 sometimes puzzled. Does the API between the kernel and user level send the enable HyperZ 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 kernel 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 bit. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 --- Comment #1 from Richard Thier --- Created attachment 144510 --> https://bugs.freedesktop.org/attachment.cgi?id=144510=edit Second screenshot (visible tile boundary - zbuffer is completely wasted below) Added second screenshot. You can see the tile here where the blue gear is. Above the line that tile starts and above the line from the next tile-line there is good z-buffer always. Here I am after some seconds so the whole zbuffer became unusable at this point and that is why things are black. In games that have a skybox I tend to see the skybox instead or far away things instead of black! Resolution is 1024x768 so you can even measure the size of the tile. I think it is 32x32 or similar. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)
https://bugs.freedesktop.org/show_bug.cgi?id=110897 Bug ID: 110897 Summary: HyperZ is broken for r300 (bad z for some micro and macrotiles?) Product: Mesa Version: git Hardware: Other OS: other Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 Assignee: dri-devel@lists.freedesktop.org Reporter: u9v...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 144505 --> https://bugs.freedesktop.org/attachment.cgi?id=144505=edit first screenshot (still not completely ruined zbuffer) Hello everyone! I went on and tried RADEON_HYPERZ=1 with my r300 card and I see bad glitches - while in the same time elevated performance. See attached screenshot(s). This affect every application, even the simplest ones like glxgears. The top of the screen is rendering properly always, but around the 25% of the screen it starts to break down and I can see tiles where things seem to have a really bad z-value. What is also interesting is that [b]I feel the z-clear is the operation that is happening wrong[/b]! I am pretty sure in this because at the first few frames of glxgears I can nearly see all the gears and as the gears turn, I see less and less of them - it kind of feels that whenever some pixel got rendered, its place cannot be used anymore - or likely cannot be used! If I turn the wheels some times around the Y axis the bottom 2/3 of the screen just becomes completely dark after a while. If I exit glxgears - or any app in question of testing - and restart it from the terminal however, I see that everything is immediately wrong! So [b]the problem persists between multiple runs of the same program with same sized window[/b] and this also hints that the z buffer is never properly (or at all) cleared! BUT [b]resizing the window immediately fixes the current frame[/b] with seemingly proper Z-values and if I keep resizing I can see a constant flickering - but a much more clear image. I think the resize operation triggers some resize in the buffers that cleans them properly, but in the very first second it already gets wrong again pretty much and this is what is happening. Also while resizing the window I saw that [b]there is no straight horizontal cut above which things are good and below which things are bad, but I literally see only the number of (macro?)tiles count from the top-left corner![/b] So basically I can see the side of one of the macrotiles. I tried to picture this with a screenshot, but it is not that easy to resize that way. See the second sceenshot that does not have anything on the bottom, but you see the cut and the left side of the tile where first things got wrong. Also the order of how the tiles go wrong is not always linear, but the first ones always work - from top-left going just like pixels. I am trying to use documentation that I have found here: http://renderingpipeline.com/graphics-literature/low-level-gpu-documentation/ Of course the r300 register docs should be good I hope, but I started reading through the r500_acceleration docs as it seems many-many of it applies to all r300 cards. Am I right that these are the best sources so far? To be honest I think the fast z-clear maybe is the problem and is badly configured to only clear the top few tiles on the screen or something similar. The tiles are approximately 32x32 or 16x16, but surely not just 1-2 pixels as they are pretty much visible to the naked eye (see second attachment screenshot). I have just barely started my analysis, so I still have a lot of directions to take and the docs (if they are good) are really helpful at least! I did not know about them so far!!! Currently playing around the code to see if I can help the problem disappear. This is likely never worked. I do not know of any version where this worked on my machine, but I cannot completely rule it out of course. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
