Comment # 2
on bug 110897
from Richard Thier
Created attachment 144512 [details] [review] 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
