On Sat, Mar 9, 2013 at 1:35 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote:
Looks a sensible thing to do.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Thanks for the review.
Any
On Sat, Mar 9, 2013 at 9:43 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote:
Looks a sensible thing to do.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Thanks for the review.
Any insight how the caller can
Looks a sensible thing to do.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Any insight how the caller can be fixed so that this doesn't happen?
Jose
- Original Message -
With the current code, the sampler count can become higher than
PIPE_MAX_SAMPLERS and once it gets to the driver
On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote:
Looks a sensible thing to do.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Thanks for the review.
Any insight how the caller can be fixed so that this doesn't happen?
It happens to me when draw stages add more
- Original Message -
On Sat, Mar 9, 2013 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote:
Looks a sensible thing to do.
Reviewed-by: Jose Fonseca jfons...@vmware.com
Thanks for the review.
Any insight how the caller can be fixed so that this doesn't happen?
It
With the current code, the sampler count can become higher than
PIPE_MAX_SAMPLERS and once it gets to the driver this can lead to
miscellaneous crashes and memory corruptions.
Although this is taken care of in debug mode with an assert,
there is still a way to cause a crash/overflow in release