Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.
On 17 September 2013 11:39, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
--- dlls/wined3d/volume.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 88 insertions(+), 7 deletions(-)
Can't most of this be done on the resource level instead?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-17 13:55, schrieb Henri Verbeet:
On 17 September 2013 11:39, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
--- dlls/wined3d/volume.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 88 insertions(+), 7 deletions(-)
Can't most of this be done on the resource level instead? Yes, but I'd prefer to migrate surfaces and buffers to the new location flags and clean up VBO/PBO handling before merging the map implementations. I also think it's better to have the tests in place without lots of todos before such a restructuring.
Error checking is a fairly minor detail in this in my opinion. The more interesting part is MAP_DISCARD handling, especially with regard to the command stream. I have the surface cleanup partially done, buffers are still on the todo list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOFHiAAoJEN0/YqbEcdMw72EP/iEWJ0WE2Ayrm4mMsXZ6uNsi brxk0en0ltGfS5AonYefFfsHsdxRwvP/J+ybbR8fx4/vBtGpN40bGECk1kV1iyBp WjdfC4RINVh/blHl+DFjKEGfHhb2uodxIFiClEzd5QNRLVzZzJdfh1+DGEZWtcdy Kkkd3xwzYS9LJFRsIJ4UhG3JP/0N+2Vvqt8NnOq0ZCXFcurnmgKAzg7qYvsPaT7r 2bhLz6QXHXOCR9W8ZDMGJM58xYesJ02ctQTpj0xxQdq5bfhmRXcRjqv1vikHKq7+ sPUrtOdH+/FsliM0qY8LUIb4jbG5SDCEx1ZIvcmQR0MftgYHoTY36LOQy5n4L0lk ChMsAGIZlJMW0So/L88yyE0pyFnbYp5xK7oVA4WazxtTIIb89OhlqtERc31pYD// 6PVpzaGe4+z7c+qXRF/TiYSVJwD/Ff//n2UdR9mbQiJmkUYjFIXsQNoD8Ep1j6fw J8oXvWgUDQRre3asoxNFadpNYBrHxb4+xypaIfCitKoJDJ6lOYvUiKSSZOOITAd1 yOCWJUy37HqCvKt4h7S9HhXFTNY2Gx7JBnMWRdABBjw+VuFHVNK09hJdcAFcX2ZK ry0TYXFebTkIlBVXXjUFpDczg+dgYmqWOOPSC3xZac+9BMR5H8ERr3dUMyT73DnR 7qowSJjPsi330yrIOPSu =BfCu -----END PGP SIGNATURE-----
On 17 September 2013 14:58, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-09-17 13:55, schrieb Henri Verbeet:
On 17 September 2013 11:39, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
--- dlls/wined3d/volume.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 88 insertions(+), 7 deletions(-)
Can't most of this be done on the resource level instead? Yes, but I'd prefer to migrate surfaces and buffers to the new location flags and clean up VBO/PBO handling before merging the map implementations. I also think it's better to have the tests in place without lots of todos before such a restructuring.
I was mostly thinking of merging e.g. wined3d_surface_get_pitch() and wined3d_volume_get_pitch() into wined3d_resource_get_pitch(). I don't feel strongly about doing that first though, so if you're saying you'll get to that eventually that's ok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-17 15:05, schrieb Henri Verbeet:
I was mostly thinking of merging e.g. wined3d_surface_get_pitch() and wined3d_volume_get_pitch() into wined3d_resource_get_pitch(). I don't feel strongly about doing that first though, so if you're saying you'll get to that eventually that's ok. The rough plan is to make load_location, validate_location and invalidate_location generic for all resources, with a resource-type specific callback for load_location. resource_map will load or validate LOCATION_SYSMEM, LOCATION_BUFFER, LOCATION_USERPTR or LOCATION_DIB, map the GL buffer and calculate the correct offset.
It will need some information about the error checking behavior, e.g. if nested maps are allowed. A field is needed to specify the correct map memory (sysmem, buffer, user-specified memory, dib section). The resource can flush the correct memory ranges in the BO, but loading the GL texture or renderbuffer has to be handled by surfaces and volumes. With the CS, the resource code will also handle swapping the sysmem pointer and buffers in case of DISCARD maps. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOFfkAAoJEN0/YqbEcdMwf/cQAIp3gD1NVYaPEwFVeIOyxbTM Nw18Qic08B40TsWwS8RYPyFU19Y4hcQhuVIw9iGOSxqst3zv+NTHfQzQ1bPw+Bfo 13l3hTJSeE+zFaaaGy8EZiZDNAxF6DDfdRyULLGdLUUjEhjTV2F4Z7dfhh8YYOVW nETdayk2pxX3FisP7LOQOFwM5juXYn5/UarWXDYeXTv1KAFXVSEE2wFC5Q8FVLQk YBW2WYXYw9a/1s+kvYk2l9vcSMgyq0JqbyjjX8oE/IuVZ8E1OwBS5QyvKZoA17sy y7hAqjL3yhjLWtp1ElnDL2mXhjfL3rXBILaGURAp1WnRXk5FMhMl+tPuX8ANfL6d RkxfBAf1jc8STB1vmP0DG2nL4eyAtriu+27WMmUKaqXKF+8z5lAgdYeZTywBldLR 6NYMfVFcv+nPgtSBW41BodTPtWMRzxJtefTVaVTnjhIwVuVFFwhV5hVLJoTZhA+f TXtmgC2OxryeSSPv0DCcUkTAEI8SNYs8Nl0ZBaPrIkPJnVBrtK5aAiY10plWQ7zB oU57w3GCI+VxOnKL26VmBj1c+mxrip49dsqlzvOC8mGPfh3PkGEYaqUzv3apJZ/O kbBemp1+uF0eXdH0FPx0jfh4KyJdo9smNaVetVSSdnZoeXebJ06Y7zSf3poiFQiY /jZgCSoInE41umVDpJbd =5pXV -----END PGP SIGNATURE-----
participants (2)
-
Henri Verbeet -
Stefan Dösinger