| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Setting intel->Fallback = 1 clobbered any fallback state that was already
set. Not sure where this hack originated (the git history is a little
convoluted). Define and use a new BRW_FALLBACK_DRAW bit instead. This
shouldn't break anything and could potentially fix some bugs (but no
specific ones are known).
|
| | |
|
| |
| |
| |
| |
| | |
The value was probably wrong too.
It was the same as INTEL_FALLBACK_DRAW_BUFFER.
|
| |
| |
| |
| | |
Driver Makefiles can still add symlink dependencies/rules if needed.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
Again, last valid address, not first invalid address. Fixes regression
in 255e5be265133280293bbfd8b2f9b74b2dec50bb that the kernel now catches
and caused piglit draw_elements_base_vertex to fail.
|
| |
| |
| |
| |
| |
| |
| |
| | |
It's the address of the last valid byte, not the address of the first
invalid byte.
This should also fix problems with rendering with the new sanity checks in
the kernel.
|
| | |
|
| |
| |
| |
| | |
This appears to shave about 3% off the CPU usage in cairo-gl for firefox.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Once we've freed a miptree, we won't see any more state cache requests
that would hit the things that pointed at it until we've let the miptree
get released back into the BO cache to be reused. By leaving those
surface state and binding table pointers that pointed at it around, we
would end up with up to (500 * texture size) in memory uselessly consumed
by the state cache.
Bug #20057
Bug #23530
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/drivers/dri/intel/intel_clear.c
|
| |
| |
| |
| |
| | |
Its flagging of extra state that's already flagged by the vtbl new_batch
when appropriate was confusing my tracking down of the OA clear bug.
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/vbo/vbo_exec_array.c
|
| |
| |
| |
| |
| |
| |
| | |
This is similar to what r300 does inside the driver, but I've added it as
a generic option since it seems most hardware will want it.
Fixes piglit nv-init-zero-reg.vpfp and nv-init-zero-addr.vpfp.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This was a regression in 0f328c90dbc893e15005f2ab441d309c1c176245.
Bug #23688
Bug #23254
(cherry picked from commit 5604b27b9326ac542069a49ed9650c4b0d3e939a)
|
| |
| |
| |
| |
| |
| |
| | |
Previously, it was trying to mess around with the varying's
WM setup data to produce a result. Along with not actually working when
passed a varying, this wouldn't work if you did dFd[xy]() on a temporary.
Instead, just calculate the derivative using the neighbors in the subspan.
|
| |
| |
| |
| |
| |
| | |
Passes piglit glsl-vs-loop testcase.
Bug #20171
|
| |
| |
| |
| |
| |
| |
| | |
This was a regression in 0f328c90dbc893e15005f2ab441d309c1c176245.
Bug #23688
Bug #23254
|
|\| |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
Makefile
configs/default
progs/glsl/Makefile
src/gallium/auxiliary/util/u_simple_shaders.c
src/gallium/state_trackers/glx/xlib/xm_api.c
src/mesa/drivers/dri/i965/brw_draw_upload.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/intel/intel_context.h
src/mesa/drivers/dri/intel/intel_pixel.c
src/mesa/drivers/dri/intel/intel_pixel_read.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
|
| | | |
|
| | |
| | |
| | |
| | | |
(cherry picked from commit df70d3049a396af3601d2a1747770635a74120bb)
|
| | |
| | |
| | |
| | |
| | |
| | | |
We could have mapped the wrong set of draw buffers. Noticed while looking
into a DRI2 glean ReadPixels issue.
(cherry picked from commit afc981ee46791838f3cb83e11eb33938aa3efc83)
|
| | |
| | |
| | |
| | | |
(cherry picked from commit 99174e7630676307f618c252755a20ba61ad9158)
|
| | |
| | |
| | |
| | |
| | | |
(cherry picked from commit a70e1315846cd5e8d6f2b622821ff8262fe7179d)
(cherry picked from commit 29e51c3872531366570d032147abad50f8a3c1af)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For some IZ setups, we'd forget to account for the source depth register
being present, so we'd both read the wrong reg, and write output depth to
the wrong reg.
Bug #22603.
(cherry picked from commit f44916414ecd2b888c8a680d56b7467ccdff6886)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes piglit glsl-vs-if-bool and progs/glsl/twoside, and will likely be
useful for the looping code.
Bug #18992
(cherry picked from commit 78c022acd0b37bf8b32f04313d76255255e769c1)
(cherry picked from commit 63d7a2f53fb38e170f4e55f2b599e918edf2c512)
|
| | |
| | |
| | |
| | | |
(cherry picked from commit fd7d764514c540987549c3ea88a2d669b0f0ea58)
|
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, we'd be branching based on whatever condition code happened to be
laying around.
(cherry picked from commit 7007f8b352763af89805f287153cb7972bff0523)
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Bug #20821
(cherry picked from commit 191e028de20b2f954621b652aa77b06d0e93652a)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This avoids sending a bad buffer address to the GPU due to programmer error,
and is permitted by the ARB_vbo spec. Note that we still have the opportunity
to dereference past the end of the GPU, because we aren't clipping to a
correct _MaxElement, but that appears to be harder than it should be. This
gets us the 90% solution.
Bug #19911.
(cherry picked from commit d7430d942f6c7950a92367aeb13b80cf76ccad78)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
See comment on Vertex URB Entry Read Length for VS_STATE.
This, combined with the previous three commits, fixes #22945.
(cherry picked from commit e340d4f9866db4bae391288e83a630a310b0dd2b)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fix is just from code and docs inspection, but it may fix hangs on
some applications.
(cherry picked from commit e93848e595176ae0bad3bfe64e0ca63fd089bb72)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It appears that sometimes Mesa (and I suppose a VS could as well) emits
a program which references no vertex data, and thus we end up with
nr_enabled == 0 even though some VBs are enabled. We'd end up emitting
VB/VE packet headers of 0xffffffff in that case, leading to GPU hangs.
Bug #22945 (wine with an uncompiled VS)
(cherry picked from commit d1fbfd0f962347e4153db3852292d44de5aea863)
|
| | |
| | |
| | |
| | |
| | | |
The code duplication bothered me.
(cherry picked from commit 9b9cb30d128fc5f1ba77287696ecd508e640efde)
|
| | |
| | |
| | |
| | |
| | | |
It's the last addressable byte, not the byte after the end of the buffer.
(cherry picked from commit b72dea5441e8e9226dabf1826fa3bc129c7bc281)
|
| | |
| | |
| | |
| | | |
(cherry picked from commit 840c09fc71542fdfc71edd2a2802925d467567bb)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes everything-black with meta_clear_tris on quake4-mpdemo and doom3-demo.
Bug #18844, 22077.
(cherry picked from commit 81d555068408d4343d7627c8bedda5675f09bd21)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
the driver used to overwrite grf0 then use implicit move by send instruction
to move contents of grf0 to mrf1. However, we must not overwrite grf0 since
it's still used later for fb write.
Instead, do the move directly do mrf1 (we could use implicit move from another
grf reg to mrf1 but since we need a mov to encode the data anyway it doesn't
seem to make sense).
I think the dp_READ/WRITE_16 functions may suffer from the same issue.
While here also remove unnecessary msg_reg_nr parameter from the dataport
functions since always message register 1 is used.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Thanks to branching, the state of c->current_const[i].index at the point
of emitting constant loads for this instruction may not match the actual
constant currently loaded in the reg at runtime. Fixes a regression in my
GLSL program for idr's class since b58b3a786aa38dcc9d72144c2cc691151e46e3d5.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
glsl compiler will not generate OPCODE_SWZ, and as a first step it would
be translated away to a MOV anyway (why?), but later internally this opcode is
generated (for EXT_texture_swizzling).
(cherry picked from commit 4ef1f8e3b52a06fcf58f78c9c36738531b91dbac)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With 1D textures, GL_TEXTURE_WRAP_T should be ignored (only
GL_TEXTURE_WRAP_S should be respected). But the i965 hardware
seems to follow the value of GL_TEXTURE_WRAP_T even when sampling
1D textures.
This fix forces GL_TEXTURE_WRAP_T to be GL_REPEAT whenever 1D
textures are used; this allows the texture to be sampled
correctly, avoiding "imaginary" border elements in the T direction.
This bug was demonstrated in the Piglit tex1d-2dborder test.
With this fix, that test passes.
(cherry picked from commit ab6c4fa582972e25f8800c77b5dd5b3a83afc996)
|