aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri
Commit message (Collapse)AuthorAgeFilesLines
...
* | | radeon: glReadBuffer set _NEW_BUFFERS, not _NEW_PIXELJerome Glisse2009-05-123-4/+4
| | | | | | | | | | | | | | | This was broken with last merge see 62043b27575c378c027251316421e4699f461108 for explanations
* | | r300/r500: make sure we detect constant buffer changesJerome Glisse2009-05-121-1/+1
| | | | | | | | | | | | | | | This was broken with last merge see f48473e42511f8d37a239a07f791bc0a87209e5b for explanations.
* | | radeon: avoid segfault in radeon_update_renderbuffers() if using DRI1Tormod Volden2009-05-121-3/+4
| | | | | | | | | | | | | | | | | | Basically the same as 43d9020ff1e975e7f4f9480d9ef24f0b9fb2141f for intel. Bug 21688. Signed-off-by: Tormod Volden <[email protected]>
* | | radeon: add support for new dri2 interfaces & fix single buffer renderingJoel Bosveld2009-05-103-16/+154
| | |
* | | Merge commit 'origin/master' into radeon-rewriteJerome Glisse2009-05-1039-636/+1435
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/mesa/drivers/dri/r200/r200_state.c src/mesa/drivers/dri/r300/r300_context.h src/mesa/drivers/dri/r300/r300_fragprog.c src/mesa/drivers/dri/r300/r300_state.c src/mesa/drivers/dri/r300/r300_texmem.c src/mesa/drivers/dri/r300/r300_texstate.c src/mesa/drivers/dri/r300/r500_fragprog.c src/mesa/drivers/dri/radeon/radeon_screen.c src/mesa/drivers/dri/radeon/radeon_state.c
| * | i965: improve debug loggingRobert Ellison2009-05-083-14/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looking for memory leaks that were causing crashes in my environment in a situation where valgrind would not work, I ended up improving the i965 debug traces so I could better see where the memory was being allocated and where it was going, in the regions and miptrees code, and in the state caches. These traces were specific enough that external scripts could determine what elements were not being released, and where the memory leaks were. I also ended up creating my own backtrace code in intel_regions.c, to determine exactly where regions were being allocated and for what, since valgrind wasn't working. Because it was useful, I left it in, but disabled and compiled out. It can be activated by changing a flag at the top of the file.
| * | i965: fix memory leak in context/renderbuffer region managementRobert Ellison2009-05-081-4/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A temporary change to the intelMakeCurrent() function to make it work with frame buffer objects causes the static regions associated with the context (the front_region, back_region, and depth_region) to take on an additional reference, with no corresponding release. This causes a memory leak if a program repeatedly creates and destroys contexts. The fix is the corresponding hack, to unreference these regions when the context is deleted, but only if the framebuffer objects are still present and the same regions are still referenced within. Both sets of code have comment blocks referring to each other.
| * | i965: fix segfault on low memory conditionsRobert Ellison2009-05-081-0/+7
| | | | | | | | | | | | | | | | | | | | | When out of memory (in at least one case, triggered by a longrunning memory leak), this code will segfault and crash. By checking for the out-of-memory condition, the system can continue, and will report the out-of-memory error later, a much preferable outcome.
| * | intel: Add a metaops version of glGenerateMipmapEXT/SGIS_generate_mipmaps.Eric Anholt2009-05-0810-76/+303
| | | | | | | | | | | | | | | | | | | | | In addition to being HW accelerated, it avoids the incorrect (black) rendering of the mipmaps that SW was doing in fbo-generatemipmap. Improves the performance of the mipmap generation and drawing in fbo-generatemipmap by 30%.
| * | intel: Put the constant texcoords used in metaops into a vbo.Eric Anholt2009-05-085-40/+102
| | | | | | | | | | | | | | | | | | | | | Make this be its own function for setup/teardown of the binding of these texcoords. No performance difference in the engine demo (I just felt dirty not using a VBO for this), and I think it should be more resilient to interference from current GL state.
| * | i965: const qualifiersBrian Paul2009-05-081-2/+2
| | |
| * | i965: don't use GRF regs 126,127 for WM programsBrian Paul2009-05-082-5/+28
| | | | | | | | | | | | | | | | | | | | | They seem to be used for something else and using them for shader temps seems to lead to GPU lock-ups. Call _mesa_warning() when we run out of temps. Also, clean up some debug code.
| * | i965: relAddr local var (to make debug/test a little easier)Brian Paul2009-05-071-5/+6
| | |
| * | i965: Remove bad constant buffer constant-reg-already-loaded optimization.Eric Anholt2009-05-061-13/+11
| | | | | | | | | | | | | | | | | | | | | 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.
| * | intel: Unmap buffers if needed at DeleteBuffer time.Eric Anholt2009-05-061-1/+10
| | | | | | | | | | | | | | | | | | | | | This fixes a crash in glean's pbo test, which tripped over the assert when a context was destroyed while a buffer was still mapped (Mesa doesn't call UnmapBuffer in that case). Regression in c6bde8873fbda6d8467600b7491d8543c75b0509
| * | i965: Remove the forced lack of caching for renderbuffer surface state.Eric Anholt2009-05-061-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This snuck in with the multi-draw-buffers commit, and is a major penalty to performance. It doesn't appear to be required, as the only dependency the surface BO has is on the state key (and if there's some other dependency, it should just be in the key). This brings openarena performance up to almost 2% faster than Mesa 7.4.
| * | i965: Remove _NEW_PROGRAM from brw_wm_surfaces setup dependencies.Eric Anholt2009-05-061-2/+1
| | | | | | | | | | | | This was a leftover from the brw_wm_constant_buffer change.
| * | i965: Split WM constant buffer update from other WM surfaces.Eric Anholt2009-05-065-90/+95
| | | | | | | | | | | | | | | | | | | | | | | | This can avoid re-uploading constant data when it isn't necessary, and is a step towards not updating other surfaces just because constants change. It also brings the upload of the constant buffer next to the creation. This brings openarena performance up another 4%, to 91% of the Mesa 7.4 branch.
| * | i965: Disentangle VS constant surface state from WM surface state.Eric Anholt2009-05-067-186/+255
| | | | | | | | | | | | | | | Also, only create VS surface state if there's a VS constant buffer to be uploaded, and set the contents of the buffer at the same time as creation.
| * | i965: Don't create constant buffers if they won't be used.Eric Anholt2009-05-061-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | Really, the creation and upload of constants should be in the same place, since they should only happen together, and a state flag should be triggered by them so that we don't thrash state around so much for just updating constants. But this still recovers openarena performance by another 19%, leaving us 16% behind Mesa 7.4 branch.
| * | mesa: in glReadBufer() set _NEW_BUFFERS, not _NEW_PIXELBrian Paul2009-05-014-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since GL_READ_BUFFER is historically part of the gl_pixel_attrib group it made sense to signal changes with _NEW_PIXEL. But now with FBOs it's also part of the framebuffer state. Now _NEW_PIXEL strictly indicates pixels transfer state changes. This change avoids framebuffer state validation when any random bit of pixel-transfer state is set. DRI drivers updated too: don't check _NEW_COLOR when updating framebuffer state. I think that was just copied from the Xlib driver because we care about dither enable/disable state there.
| * | Test either GL_FRONT_LEFT or GL_FRONT for front-buffer renderingIan Romanick2009-05-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For non-stereo visuals, which is all we support, we treat GL_FRONT_LEFT as GL_FRONT. However, they are technically different, and they have different enum values. Test for either one to determine if we're in front-buffer rendering mode. This fix was suggested by Pierre Willenbrock. Signed-off-by: Ian Romanick <[email protected]>
| * | Merge branch 'const-buffer-changes'Brian Paul2009-05-0114-200/+350
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | Conflicts: src/mesa/drivers/dri/i965/brw_curbe.c src/mesa/drivers/dri/i965/brw_vs_emit.c src/mesa/drivers/dri/i965/brw_wm_glsl.c
| | * i965: #include prog_print.h to silence warningBrian Paul2009-04-271-0/+1
| | |
| | * i965: only upload constant buffer data when we actually need the const bufferBrian Paul2009-04-276-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Make the use_const_buffer field per-program and only call the code which updates the constant buffer's data if the flag is set. This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052 (cherry picked from master, commit dc9705d12d162ba6d087eb762e315de9f97bc456)
| | * i965: rework GLSL/WM register allocationBrian Paul2009-04-242-48/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | Use a bitvector of used/free flags. If we run out of temps, examine the live intervals of the temp regs in the program and free those which are no longer alive. Also, enable the new WM const buffer code.
| | * i965: disable debug printfBrian Paul2009-04-221-1/+1
| | |
| | * i965: enable VS constant buffersBrian Paul2009-04-221-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the VS constants can now be handled in two different ways: 1. If there's room in the GRF, put constants there. They're preloaded from the CURBE prior to VS execution. This is the historical approach. The problem is the GRF may not have room for all the shader's constants and temps and misc registers. Hence... 2. Use a separate constant buffer which is read from using a READ message. This allows a very large number of constants and frees up GRF regs for shader temporaries. This is the new approach. May be a little slower than 1. 1 vs. 2 is chosen according to how many constants and temps the shader needs.
| | * i965: define BRW_MAX_GRFBrian Paul2009-04-221-0/+3
| | |
| | * i965: remove old code to init surface-related cache IDsBrian Paul2009-04-221-14/+0
| | | | | | | | | | | | These types are only found in the new surface state cache now.
| | * i965: comments, reformattingBrian Paul2009-04-221-17/+38
| | |
| | * i965: actually use the new, second surface state cacheBrian Paul2009-04-221-17/+22
| | |
| | * i965: checkpoint commit: use two state caches instead of oneBrian Paul2009-04-224-45/+88
| | | | | | | | | | | | | | | | | | | | | The new, second cache will only be used for surface-related items. Since we can create many surfaces the original, single cache could get filled quickly. When we cleared it, we had to regenerate shaders, etc. With two caches, we can avoid doing that.
| | * i965: remove unused state atom entriesBrian Paul2009-04-221-9/+1
| | |
| | * i965: the brw_constant_buffer state atom is no longer dynamicBrian Paul2009-04-222-33/+5
| | | | | | | | | | | | No more dynamic atoms so we can simplify the state validation code a little.
| | * i965: add _NEW_PROGRAM_CONSTANTS to mesa_bits[] listBrian Paul2009-04-221-0/+1
| | |
| | * i915: check the new _NEW_PROGRAM_CONSTANT flagBrian Paul2009-04-221-1/+1
| | |
| | * i965: use _NEW_PROGRAM_CONSTANTS and always create new const buffersBrian Paul2009-04-221-14/+14
| | | | | | | | | | | | | | | | | | When program constants change we create a new VS constant buffer instead of re-using the old one. This allows us to have several const buffers in flight with vertex rendering.
| | * i965: updates to some debug codeBrian Paul2009-04-221-6/+6
| | |
| | * i965: use new _NEW_PROGRAM_CONSTANTS flag instead of dynamic flagsBrian Paul2009-04-221-8/+1
| | |
| | * r200/r300/r500: add _NEW_PROGRAM_CONSTANTS flagBrian Paul2009-04-224-6/+10
| | | | | | | | | | | | | | | | | | Make sure we detect constant buffer changes indicated by the new flag. Should be able to remove _NEW_PROGRAM (and _NEW_MODELVIEW, _NEW_LIGHT, etc) from several places (someday.
| * | r300: Increase reference count of texture objects referenced by current state.Michel Dänzer2009-04-304-9/+11
| | | | | | | | | | | | | | | | | | | | | Fixes a use-after-free reported in http://bugs.freedesktop.org/show_bug.cgi?id=20539, so this possibly fixes that bug. It has been confirmed to fix http://bugs.freedesktop.org/show_bug.cgi?id=17895 .
| * | R300: add quadpipe overridesAlex Deucher2009-04-281-4/+13
| | | | | | | | | | | | | | | RV410 SE chips only have 1 quadpipe. Also, handle other R300 chip with quadpipe override
| * | i965: avoid segfault in intel_update_renderbuffers() if using DRI1Brian Paul2009-04-281-3/+4
| | |
| * | i965: only upload constant buffer data when we actually need the const bufferBrian Paul2009-04-276-17/+17
| | | | | | | | | | | | | | | | | | | | | Make the use_const_buffer field per-program and only call the code which updates the constant buffer's data if the flag is set. This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
| * | r300: always emit output insts after all KIL instsMaciej Cencora2009-04-272-3/+46
| | |
| * | intel: Fix more issues with the combined depth-stencil attachmentIan Romanick2009-04-241-6/+13
| | |
| * | intel: Initialize region ptr to prevent assertion in intel_region_referenceIan Romanick2009-04-241-1/+1
| | |
| * | intel / DRI2: When available, use DRI2GetBuffersWithFormatIan Romanick2009-04-242-16/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This interface gives the driver two important features. First, it can allocate the (fake) front-buffer only when needed. Second, it can tell the buffer allocator the format of buffers being allocated. This enables support for back-buffer and depth-buffer with different bits per pixel. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
| * | i965: use drm_intel_gem_bo_map/unmap_gtt() when possible, otherwise ↵Brian Paul2009-04-241-5/+9
| | | | | | | | | | | | | | | | | | dri_bo_subdata() This wraps up the unfinished business from commit a9a363f8298e9d534e60e3d2869f8677138a1e7e
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-13 21:33:51 +0000