| Age | Commit message (Collapse) | Author |
|---|
|
The idea would be that you could have multiple send messages going on
if nothing depended on the previous message's results and you used a
different send message. The problem is that the later send requires
the VUE handle returned by the first send's allocate anyway.
|
|
|
|
|
|
|
|
|
|
The test for env['platform'] caused an exception since 'env' is not
defined at that point. Instead, determine the target platform by
scanning sys.argv[].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Before we would throttle in the flush callback prior to round-tripping
to the server to do copyregion or swapbuffer. Now, instead just note
that we need to throttle and do it in intel_prepare_render(), which
will be called after receiving the response from the server but before
we start rendering the next frame. Even if the server also throttles
us in swapbuffer, this just makes the throttling a no-op when we hit
intel_prepare_render(). With that we can drop the
using_dri2_swapbuffers hack and just always throttle.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
prevents segfault when state trackers try to set default mask.
Other option would be to make this required only for drivers
supporting multisampling, but this seems more clean.
Only dummy implementations (for normal drivers) provided (no driver
supports multisampling yet neither).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
compile tested only.
Should probably change the python surface_copy/fill functions
also into resource_copy/fill_region functions and adapt the code
using them.
|
|
might need further cleanup. Using surfaces internally just to be able to use
the existing code might cause unnecessary copies afaict.
|
|
might need further cleanup. Using surfaces internally for the u_blitter code
seems nonoptimal.
|
|
this probably needs further cleanup (just getting a surface for the resource
seems quite nonoptimal and potentially cause unnecessary copies I think)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not even compile tested but fairly trivial
|
|
adapt to blit changes, and also handle a bit more msaa state in theory
(incomplete, doesn't handle resolves in any way for now).
|
|
The util blit functions change their interface (apart from some rename) too
(in particular util_blit_pixels now also takes a pipe_resource as the src blit
argument instead of a surface, as it might just call resource_copy_region).
Maybe the blit util code might need a bit more cleanup, it still doesn't feel
very clean. In particular it seems that util_blit_pixels_tex should probably
disappear, and I think it would be great if the code called by drivers for
blitting (u_blitter.c, which isn't really touched by this change) could somehow
be merged with the u_blit code.
|
|
Previously, surface_copy was said to allow overlapping blits, and it was
"optional". However, some state trackers actually assumed it is always present,
and quite some code (like in u_blit) assumed overlapping isn't allowed.
Hence, resource_copy_region (and in the same spirit, resource_fill_region) is
now mandatory, but overlapping blits are no longer allowed. A driver can plug
in the cpu fallback util_resource_copy_region if it does not want to provide its
own implementation, though this is not optimal.
|
|
due to popular request, use nr_samples parameter in is_format_supported()
instead of new is_msaa_supported() query.
This makes it easily possible to query if a format with a given sample count
is also supported not only as render target, but for sampler views (note that
texture sampling from multisampled resources isn't supported yet).
It is not quite how dx10 format msaa queries work, but we might need to revisit
format queries completely in the future anyway.
|
|
|
|
|
|
|
|
|
