On 29.11.2017 08:10, Sahu, Satyajit wrote:
On 11/28/2017 9:33 PM, Nicolai Hähnle wrote:
On 28.11.2017 09:34, Sahu, Satyajit wrote:
[snip]
--- a/src/gallium/targets/dri/dri.sym
+++ b/src/gallium/targets/dri/dri.sym
@@ -4,6 +4,11 @@
__driDriverGetExtensions*;
nouveau_drm_screen_create;
radeon_drm_winsys_create;
+ ac_compute_surface;
+ ac_query_gpu_info;
+ ac_read_write_tiled_data;
+ amdgpu_addr_create;
+ amdgpu_addr_destroy;
NAK.
I told you in internal discussions already that we shouldn't expose
new public symbols, we're arguably already exposing too much.
We need to expose certain addrlib functions in order get functionalities
like bo create, bo map (get linear data from tiled).
Please use the extension mechanism that is already there.
Are you suggesting to add a driExtension to expose addrlib functions?
Yes, if it is really needed.
By the way, are you sure read_write_tiled is going to work like that?
What if the surface has DCC?
Yes I have tested it on chromiumos, it works fine. When dumped the
linear data, the image is proper. One of the chromium test case which
does a bit comparison with reference image also passes.
That doesn't really answer the question though :)
Just because one or two tests pass, that doesn't mean the code is
actually correct.
Cheers,
Nicolai
This can be the case for a surface exported by radeonsi with explicit
flushing.
Cheers,
Nicolai
regards,
Satyajit
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
