| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
See commit ece0e535a44c228dd994861592deb155c14740d8. This makes
Gen4-5 follow the behavior we use on Gen6+. It seems to have
worked out there.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
| |
This brings the improved guardbanding we implemented on Gen6+
back to the older Gen4-5 code. It also deletes piles of code.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
Gen4-5 include a single SCISSOR_RECT in SF_VIEWPORT.
Making a helper function will allow us to reuse this code for Gen4-5.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
| |
This is clearer and less likely to break in the future.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
These are fairly related. Gen4-5 combine the scissor rectangle and
SF_VIEWPORT. Co-locating them will allow me to avoid forward
declarations of helper functions in a few patches.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Gen7+ we emit 3DSTATE_VIEWPORT_STATE_POINTERS_{SF_CL,CC} when
emitting a new viewport.
This patch makes us take the same approach on Sandybridge - but because
we have a combined command, we just set the appropriate "change" bits.
This eliminates an atom, some dirty flagging, and some brw->*.vp_offset
writes. It does mean we'll emit two 3DSTATE_VIEWPORT_STATE_POINTERS
instead of one if both change, but that's probably fine.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
| |
This will help us add KHR_no_error support.
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
|
| |
This allows some tidy up and also makes it so we can add KHR_no_error
support.
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
| |
This will help us add KHR_no_error support.
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
| |
This will help us implement KHR_no_error support.
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
| |
This will help us implement KHR_no_error support.
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
|
| |
This will allow us to skip the error checkes when adding
KHR_no_error support.
Reviewed-by: Iago Toral Quiroga <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
This was just an accidental typo in the refactoring. The intention was
to try the blitter on gen4-5, not just gen4.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
We keep the blit path because it's probably faster when it works.
However, now that we can use blorp, we can delete that nasty CPU
fall-back path.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The width and height of the copy don't have to be aligned to the block
size if they specify the right or bottom edges of the image. (See also
the comment and asserts right above). We need to round them up when we
do the division in order to get it 100% right.
Reviewed-by: Ben Widawsky <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Cc: "17.0 17.1" <[email protected]>
|
|
|
|
|
|
|
|
| |
We don't support replicated data clears yet. Those take a bit more work
and enabling replicated data clears in its own commit is probably better
for bisectibility anyway.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Due to complications with things such as URB setup on gen4-5, it's
easier to keep gen4 support in blorp completely internal to i965. This
makes things a bit awkward because that means there's a file in i965
that includes blorp_priv.h but it's either that or have a file in blorp
that includes brw_context.h.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
As part of enabling support for SF programs, we plumb the SF URB size
through to emit_urb_config. For now, it's always zero but, on gen4, it
may be something larger.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Having it be a pointer means that we end up caching clip programs based
on a pointer to wm_prog_data rather than the actual interpolation modes.
We've been caching one clip program per FS ever since 91d61fbf7cb61a44a
where Timothy rewrote brw_setup_vue_interpolation().
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Having it be a pointer means that we end up caching clip programs based
on a pointer to wm_prog_data rather than the actual interpolation modes.
We've been caching one clip program per FS ever since 91d61fbf7cb61a44a
where Timothy rewrote brw_setup_vue_interpolation().
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
The guts of blorp and ISL don't understand i965's partial miptrees.
Instead, we need to subtract off first_level before we hand anything off
to blorp.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
| |
ISL doesn't have a concept of a partial miptree. Instead, we need to
subtract off first_level.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The blorp_copy entrypoint is designed for doing memcpy like operations
which is what we need to do here while blorp_blit is for handling format
conversion and scaling. Using blorp_copy is much simpler and prevents
us from getting formats wrong. While we're here, we get rid of the
layers_per_blit thing since stencil always uses interleaved MSAA.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've discovered in the Vulkan driver that simply doing the end-of-pipe
sync afterwards is insufficient. The specific requirement stated in the
PRM is that you have to do one every time you transition between the
tree modes of "clear", "render", and "resolve". This is GL, so we could
track it but any attempt to do so would most likely get it wrong. For
now, it's easier to just assume that every fast-clear op is an island
and do the sync both before and after.
This also removes the unneeded flush and stall after slow-clear
operations.
Reviewed-by: Topi Pohjolainen <[email protected]>
Cc: "17.0 17.1" <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Simplify the handling of mmap for Android by using mmap64 instead. mmap64
may have not existed for Android when this was written, but it's been
around since 2013.
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
|
|
|
|
|
|
| |
type_size() will already handle this correctly for us.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
The if check above means we can only get here if size is less than 4.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mark the functions 'exec="skip"' in the XML instead. libGL will still
have the functions, but the driver won't try to use them. I verified
that this commit works with piglit's 'object-namespace-pollution glClear
vertex-array' on x64 with a driver built from mesa-12.0.3 tag.
In fairness, this test also works with a libGL built from 7927d03. I
believe it continues to work because on non-Windows platforms we
generate some extra, dummy dispatch functions that can be used when a
driver requests a function unknown to libGL. This was done to provide
some "forward" compatibility with drivers that need more functions.
This doesn't work on Windows because the Windows calling convention is
for the callee to clean up the stack. That's the theory anyway.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
| |
This platform passes the following GLES3 tests:
ES3-CTS.functional.texture.compressed.astc.endpoint_value_hdr_cem_*
Reviewed-by: Anuj Phogat <[email protected]>
Signed-off-by: Nanley Chery <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
text data bss dec hex filename
7038459 235248 37280 7310987 6f8e8b 32-bit i965_dri.so before
7038227 235248 37280 7310755 6f8da3 32-bit i965_dri.so after
6681438 303400 50608 7035446 6b5a36 64-bit i965_dri.so before
6681254 303400 50608 7035262 6b597e 64-bit i965_dri.so after
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
| |
Definitive Edition
Signed-off-by: Marek Olšák <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
APPLE_vertex_array_object support was removed in 7927d0378fc7.
However it turns out we can't remove the functions because this
can cause issues when libglapi is used together with DRI
drivers built prior to said commit
Fixes: 7927d0378fc ("mesa: drop APPLE_vertex_array_object support")
Reviewed-by: Emil Velikov <[email protected]>
|