g for mesa, it seems the issue came
from my email address domain being refused for various reasons. So, in
an attempt to fix it, I might need to send a copy of this message once
in a while.
I'm really sorry for the disturbance and the pollution that might eng
g for mesa, it seems the issue came
from my email address domain being refused for various reasons. So, in
an attempt to fix it, I might need to send a copy of this message once
in a while.
I'm really sorry for the disturbance and the pollution that might eng
g for mesa, it seems the issue came
from my email address domain being refused for various reasons. So, in
an attempt to fix it, I might need to send a copy of this message once
in a while.
I'm really sorry for the disturbance and the pollution that might eng
The "drawbuffer-modes -auto" piglit test was also failing on llvmpipe
approx. 1/5 times, and the glarea sample app had the same issue as the
softpipe. The PIPE_BIND_DISPLAY_SYNC fix seems to apply well on both
drivers.
Signed-off-by: Karl Lessard
---
src/gallium/drivers/llvmpipe/lp
I think that we do not have to force a display/drawable refresh right
after unmapping the front buffer, this could be handled later on when
the pipe is being flushed or buffers are swapped (for optimisation).
Signed-off-by: Karl Lessard
---
src/gallium/winsys/sw/dri/dri_sw_winsys.c | 13
Rename pipe_screen "resource_create_front" method to "resource_create2"
since it is not only invoked for front buffer creation (I'm not a big
fan of the '2' suffix but nothing else came up to my mind...)
Signed-off-by: Karl Lessard
---
src/gallium
The "drawbuffer-modes -auto" piglit test was also failing on llvmpipe
approx. 1/5 times, and the glarea sample app had the same issue as the
softpipe. The PIPE_BIND_DISPLAY_SYNC fix seems to apply well on both
drivers.
Signed-off-by: Karl Lessard
---
src/gallium/drivers/llvmpipe/lp
Rename pipe_screen "resource_create_front" method to "resource_create2"
since it is not only invoked for front buffer creation (I'm not a big
fan of the '2' suffix but nothing else came up to my mind...)
Signed-off-by: Karl Lessard
---
src/gallium
I think that we do not have to force a display/drawable refresh right
after unmapping the front buffer, this could be handled later on when
the pipe is being flushed or buffers are swapped.
Signed-off-by: Karl Lessard
---
src/gallium/winsys/sw/dri/dri_sw_winsys.c | 13 ++---
1 file
"snapshot" number is increased and set to both the resource and the
drawable. If the snapshot number of the front buffer does not
match the drawable one at map time, it means that another resource has
been displayed meanwhile and therefore, a refresh is required.
Signed-off-by: Karl Lessard
B
I think that we do not have to force a display/drawable refresh right
after unmapping the front buffer, this could be handled later on when
the pipe is being flushed or buffers are swapped.
Signed-off-by: Karl Lessard
---
src/gallium/winsys/sw/dri/dri_sw_winsys.c | 13 ++---
1 file
The "drawbuffer-modes -auto" piglit test was also failing on llvmpipe
approx. 1/5 times, and the glarea sample app had the same issue as the
softpipe. The PIPE_BIND_DISPLAY_SYNC fix seems to apply well on both
drivers.
Signed-off-by: Karl Lessard
---
src/gallium/drivers/llvmpipe/lp
Rename pipe_screen "resource_create_front" method to "resource_create2"
since it is not only invoked for front buffer creation (I'm not a big
fan of the '2' suffix but nothing else came up to my mind...)
Signed-off-by: Karl Lessard
---
src/gallium
"snapshot" number is increased and set to both the resource and the
drawable. If the snapshot number of the front buffer does not
match the drawable one at map time, it means that another resource has
been displayed meanwhile and therefore, a refresh is required.
Signed-off-by: Karl Lessard
B
ve a better solution :)
>>
>> Ideally, I would like to have python a requirement for developers. And
>> those
>> sources are generated when making a release tarball so that python is not
>> a
>> requirement for users.
>>
>
> I'd be in favor of
15 matches
Mail list logo
