summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* Revert "i965: Create ARGB2101010 DRI configs"Kristian Høgsberg2013-10-161-4/+1
| | | | | | | | | | | | | | | | Exposing 10-bit color configs confuses too many applications that try to use the chooser to pick an 8 bit config. The chooser consider an fbconfig with more bits a better match and will thus give a 10 bit config when an application asks for a config with GLX_RED_SIZE 1 or 8. One key example is glxinfo, which does this, and then doesn't specify that it needs a config where GLX_DRAWABLE_TYPE has the GLX_WINDOW_BIT set. This way it ends up with a 10 bit config that it can't use to create a GLX window and fails to log extensions. This reverts commit f354bcc1770e9df88db51eba5a4543a09ca6d128. https://bugs.freedesktop.org/show_bug.cgi?id=70557
* i965/fs: Handle printing HW_REGS in dump_instruction().Matt Turner2013-10-161-0/+16
| | | | | | | | | | Scheduling debugging now prints: Instructions before scheduling (reg_alloc 1) 0: linterp vgrf20, hw_reg2, hw_reg3, hw_reg4, 1: linterp vgrf21, hw_reg2, hw_reg3, hw_reg4+16, Reviewed-by: Eric Anholt <[email protected]>
* i965: Print instructions' children during scheduling debugging.Matt Turner2013-10-161-2/+6
| | | | | | | | | | | | | | | | | | Useful for tracking down problems in dependency calculations. Scheduling debugging now prints: clock 2, scheduled: linterp vgrf5, hw_reg2, hw_reg3, hw_reg0, child 0, 53 parents: fb_write (null), (null), (null), (null), child 1, 2 parents: tex vgrf4, vgrf5, (null), (null), child 2, 52 parents: placeholder_halt (null), (null), (null), (null), clock 4, scheduled: linterp vgrf5+1, hw_reg2, hw_reg3, hw_reg0+16, child 0, 52 parents: fb_write (null), (null), (null), (null), child 1, 1 parents: tex vgrf4, vgrf5, (null), (null), now available child 2, 51 parents: placeholder_halt (null), (null), (null), (null), Reviewed-by: Eric Anholt <[email protected]>
* dri: Add __DRIimage support for the ARGB2101010 formatKristian Høgsberg2013-10-151-0/+10
| | | | | | | We add support for the ARGB2101010 color format to the DRI image extension, which allows DRI loaders to create a __DRIimage with this color format. Signed-off-by: Kristian Høgsberg <[email protected]>
* i965: Create ARGB2101010 DRI configsKristian Høgsberg2013-10-151-1/+4
| | | | | | | | | This commit enables ARGB2101010 system framebuffers (that is, DRI drawables) for the i965 drivers. This is done by generating DRI configs that advertise this color format as well as teaching intelCreateBuffer to pick the right color format when it sees such a DRI config. Signed-off-by: Kristian Høgsberg <[email protected]>
* dri/common: Add support for creating ARGB2101010 configsKristian Høgsberg2013-10-151-0/+10
| | | | | | | | This extends the common dri driver infrastructure with the ability to create __DRIconfigs for 10 bits/channel + 2 bit alphs formats. This still has to be supported and requested by a driver, so this doesn't enable anthing yet. Signed-off-by: Kristian Høgsberg <[email protected]>
* i965: Add support for RGB565 __DRIimageSingh, Satyeshwar2013-10-151-0/+3
| | | | | | | | Add information for RGB565 to the table of image formats so that we can create a __DRIimage for that format. This in turn enables RGB565 wayland clients. Signed-off-by: Kristian Høgsberg <[email protected]>
* configure.ac: drop obsolete variable HAVE_COMMON_DRIEmil Velikov2013-10-151-2/+0
| | | | | | | | | | | | | | | The original intent of the variable was to prevent adding libdrm dependency for non drm drivers (swrast). This is already handled with __NOT_HAVE_DRM_H, and with the recent merge of the dri_util and drisw_util code this variable has started causing build issues. Eg. the following will fail $ ./autogen.sh --with-dri-drivers=swrast --with-gallium-drivers= $ make Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Andreas Boll <[email protected]>
* swrast: add correct include for out-of-tree buildsEmil Velikov2013-10-151-0/+1
| | | | | | | | | | | | | The xmlpool/options.h file was not accessible when building out-of-tree leading to failure. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70378 Reported-by: Fabio Pedretti <[email protected]> Tested-by: Fabio Pedretti <[email protected]> Tested-by: Andre Heider <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Andreas Boll <[email protected]>
* i965/gs: Set the REORDER bit in 3DSTATE_GS.Paul Berry2013-10-152-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Ivy Bridge's "reorder enable" bit gives us a binary choice for the order in which vertices from triangle strips are delivered to the geometry shader. Neither choice follows the OpenGL spec, but setting the bit is better, because it gets triangle orientation correct. Haswell replaces the "reorder enable" bit with a new "reorder mode" bit (which occupies the same location in the command packet). This bit gives us a different binary choice, which affects both triangle strips and triangle strips with adjacency. Setting the bit ("reorder trailing") gives the proper order according to the OpenGL spec. So in either case we want to set the bit. On Ivy Bridge, fixes piglit test "triangle-strip-orientation". On Haswell, fixes piglit tests "glsl-1.50-geometry-primitive-types {GL_TRIANGLE_STRIP,GL_TRIANGLE_STRIP_ADJACENCY}" and "glsl-1.50-geometry-tri-strip-ordering-with-prim-restart *". v2: Rename the bit to "REORDER_TRAILING" for consistency with Haswell docs. Reviewed-by: Matt Turner <[email protected]>
* i965/fs: Remove bogus field prog_data->dispatch_width.Paul Berry2013-10-153-7/+2
| | | | | | | | | | | | | | Despite the name, this field wasn't being set to the dispatch width at all; it was always 8. The only place it was used was that the constant buffer read length was aligned to it, and as far as I can tell from the docs, there is no need to align this value to the dispatch width; aligning it to a multiple of 8 is sufficient. So I've just replaced it with a hardcoded 8. v2: In gen6_wm_state, use brw->wm.base.push_const_size for consistency with VS and GS state upload. Reviewed-by: Eric Anholt <[email protected]>
* i965: Move the common binding table offset code to brw_shader.cpp.Eric Anholt2013-10-157-62/+58
| | | | | | | | | | Now that both vec4 and fs are dynamically assigning offsets, a lot of the code is the same. v2: Avoid passing around the next offset through the class. (Review by Paul) Reviewed-by: Paul Berry <[email protected]>
* i965/vec4: Dynamically assign the VS/GS binding table offsets.Eric Anholt2013-10-153-57/+25
| | | | | | | Note that the dropped comment in brw_context.h is mostly (better written) in brw_binding_table.c as well. Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Dynamically set up the WM binding table offsets.Eric Anholt2013-10-153-43/+35
| | | | Reviewed-by: Paul Berry <[email protected]>
* i965: Make a brw_stage_prog_data for storing the SURF_INDEX information.Eric Anholt2013-10-1519-115/+161
| | | | | | | | | | | It would be nice to be able to pack our binding table so that programs that use 1 render target don't upload an extra BRW_MAX_DRAW_BUFFERS - 1 binding table entries. To do that, we need the compiled program to have information on where its surfaces go. v2: Rename size to size_bytes to be more explicit. Reviewed-by: Paul Berry <[email protected]>
* i965: Always have the struct gl_program * in the backend visitor.Eric Anholt2013-10-154-14/+15
| | | | | | | vec4 already had it, so put it in the FS, too. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Drop a couple of unused defines.Eric Anholt2013-10-151-3/+0
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Remove dead arguments from prog_data_compare.Eric Anholt2013-10-158-17/+8
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Don't copy prop source mods into instructions that can't take them.Matt Turner2013-10-144-0/+26
|
* i965: Merge intel_context.h into brw_context.h.Kenneth Graunke2013-10-132-172/+120
| | | | | | | | v2: Keep the random 32-bit only version of memcpy, since Ian says I can't delete it without data proving it isn't useful. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Delete our copy of likely/unlikely macros.Kenneth Graunke2013-10-131-10/+0
| | | | | | | | brw_context.h includes imports.h which includes compiler.h which already defines these. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Move U_FIXED/S_FIXED macros from i965 to macros.h.Kenneth Graunke2013-10-132-39/+0
| | | | | | | | | | | | | | | | | These make it easy to convert a floating point value to a fixed point numbers. The second parameter is the number of bits used for the fractional part of the number. It looks like core Mesa has similar functions already, but none that allows an arbitrary number of fractional bits. The more generic version is probably useful to everyone. r600g apparently has an identical copy of the S_FIXED macro, but doesn't include this file. I'm not sure what to do about that, so I'm just going to leave it for now. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Move ROUND_DOWN_TO() macro from i915/i965 to macros.h.Kenneth Graunke2013-10-131-13/+0
| | | | | | | | | | This seems generally useful, so it may as well live in core Mesa. In fact, the comment for ALIGN() in macros.h actually says to "see also" ROUND_DOWN_TO, which...was in a driver somewhere. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move need_workaround_flush = true to intel_batchbuffer_init.Kenneth Graunke2013-10-132-2/+2
| | | | | | | | intel_batchbuffer_init() sets up initial batchbuffer state; it seems like a reasonable place to initialize this flag. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move DriverFlag initialization to brw_init_state().Kenneth Graunke2013-10-132-4/+5
| | | | | | | | Configuring which dirty flags we want sounds like a job for brw_init_state(). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Merge intelInitContext into brwCreateContext.Kenneth Graunke2013-10-132-83/+43
| | | | | | | The split here was completely arbitrary. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move viewport driver hook setup to brw_init_driver_functions.Kenneth Graunke2013-10-131-12/+12
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Make brwInitFunctions take brw_context rather than intel_screen.Kenneth Graunke2013-10-131-6/+6
| | | | | | | | | | | | It actually just wants generation checking, and brw->gen is the usual way of doing that. In the future, we'll also want to check brw->hw_ctx, which isn't available from the screen. While we're changing the function signature, convert from camel case to our usual naming conventions. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Merge intelInitFunctions() and brwInitFunctions().Kenneth Graunke2013-10-131-10/+3
| | | | | | | They do exactly the same thing. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Merge intel_context.c into brw_context.c.Kenneth Graunke2013-10-133-730/+685
| | | | | | | | | | | There's no point in having two files for context functions. This patch moves the code from intel_context.c into brw_context.c unmodified (other than whitespace fixes). Right now, this looks silly; future patches will merge functions and tidy things up. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Move memset of TextureFormatSupported to brw_init_surface_formats.Kenneth Graunke2013-10-132-3/+2
| | | | | | | | brw_init_surface_formats already sets entries in TextureFormatsSupported to true; it may as well take care of initializing it to false too. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Remove has_aa_line_parameters.Kenneth Graunke2013-10-133-3/+5
| | | | | | | | This flag is only used in one place, and is only set on one platform. Just check for original Gen4 in the relevant function. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move state setup from brwCreateContext to brw_init_state().Kenneth Graunke2013-10-132-8/+8
| | | | | | | This seems like a better place for it, and helps clean up brwCreateContext (which is full of a lot of random stuff). Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Remove the brw_context::emit_state_always flag.Kenneth Graunke2013-10-133-5/+2
| | | | | | | | This was always set to false, and is only used for debugging. To enable it, simply change the if (0) block and recompile. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move hardware feature flags to brw_device_info.Kenneth Graunke2013-10-133-4/+18
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move device quirks to brw_device_info.Kenneth Graunke2013-10-133-8/+27
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move hardware limits to brw_device_info.Kenneth Graunke2013-10-133-83/+117
| | | | | | | | | Since each kind of device has its own brw_device_info structure, we can simply store the URB and thread limits there. This eliminates all the large if-ladders, and simplifies the context initialization code quite a bit. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Replace some intel_screen fields with brw_device_info references.Kenneth Graunke2013-10-134-62/+22
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Delete the INTEL_SEPARATE_STENCIL override.Kenneth Graunke2013-10-131-27/+0
| | | | | | | | | This option was useful during initial development, but it's been ages since I've heard of anyone using it. Plus, Gen7+ mandates separate stencil, so it was really only useful on Sandybridge anyway. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Add a new brw_device_info structure.Kenneth Graunke2013-10-136-0/+150
| | | | | | | | | | | | | | | The idea is that struct brw_device_info should store statically-known information about hardware features. Using the new family name in the PCI ID table, we can easily grab the right structure. This is basically the equivalent of intel_device_info in the kernel. This patch also makes the new structure available from intel_screen, but nothing uses it. Right now, it looks very redundant with existing fields, but that will change. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Add the family name to the PCI ID table.Kenneth Graunke2013-10-131-1/+1
| | | | | | | | I removed this a while ago, since we never used it, but I'm finally resurrecting the idea in the next commits. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Remove #define name from PCI ID table.Kenneth Graunke2013-10-131-1/+1
| | | | | | | | | | Nothing uses the #define name, and it's not terribly useful - the numerical ID serves the same purpose. The only thing we could really do with it is generate slightly prettier preprocessed code. But who looks at that? Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Pull most driconf option handling into a centralized function.Kenneth Graunke2013-10-132-47/+61
| | | | | | | | | | | | | Using a helper function clarifies the context initialization code. I would've liked to completely centralize it, but moving the optionCache code from intelInitExtensions into here would've required setting flags in the context, which seems like a waste. v2: Rebase for the introduction of disable_derivative_optimization. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move a bunch of code from intelInitContext to brwCreateContext.Kenneth Graunke2013-10-132-50/+44
| | | | | | | | | | | | Now that intelInitContext isn't shared between i915 and i965, the split is fairly arbitrary. This patch moves a bunch of the basic context creation and generation checking code up to the top-level function (and slightly earlier). More will follow. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Update the comment about viewport hacks.Kenneth Graunke2013-10-131-1/+7
| | | | | | | It wasn't clear that this was necessary for EGL, or why. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Pull out INTEL_DEBUG handling into new intel_debug.[ch] files.Kenneth Graunke2013-10-135-128/+200
| | | | | | | | | | | | | Now that there isn't an intel_context structure, the split between brw_context.[ch] and intel_context.[ch] is rather awkward and arbitrary. Removing intel_context.[ch] seems desirable, but not everything really belongs in brw_context.[ch], either. Moving INTEL_DEBUG handling into separate intel_debug.[ch] files should make them relatively easy to find. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Rename brwCreateContext's error parameter to dri_ctx_error.Kenneth Graunke2013-10-131-3/+3
| | | | | | | | "error" is a very generic name. dri_ctx_error is the name used in intelInitContext(), which is more specific. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* dri: Move i965-specific context flag logic to dri common.Eric Anholt2013-10-132-8/+9
| | | | | Nobody else yet can do a forward context anyway, but others should be able to do debug contexts, and those would have just had no effect currently.
* i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.Paul Berry2013-10-122-2/+4
| | | | | | | | | | | | Geometry shaders were the last thing we needed to finish before turning on GLSL 1.50 and GL 3.2 support. They are now working well, with just a few piglit failures left to fix. Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: extend fast texture uploadFrank Henigman2013-10-101-69/+402
| | | | | | | | | | | | | | | | | | | | | Extend the fast texture upload from BGRA X-tiled to include RGBA, Alpha/Luminance, and Y-tiled. Speed improvements, measured with mesa demos teximage program, on 256 x 256 texture, in MB/s, on a Sandy Bridge (Ivy is comparable): before after increase BGRA/X-tiled 3266 4524 1.39x BGRA/Y-tiled 1739 3971 2.28x RGBA/X-tiled 474 4694 9.90x RGBA/Y-tiled 477 3368 7.06x L/X-tiled 1268 1516 1.20x L/Y-tiled 1439 1581 1.10x v2: Cosmetic changes only: reformat and reword comments, make doxygen-friendly, rename variables, use existing macros, add an assert. Signed-off-by: Frank Henigman <[email protected]> Reviewed-and-tested-by: Chad Versace <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 22:00:27 +0000