aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i965/gen4-5: Stop using bogus polygon_offset_scale field.Eric Anholt2013-06-263-20/+1
| | | | | | | | | | | | | | | | | | | | The polygon offset math used for triangles by the WM is "OffsetUnits * 2 * MRD + OffsetFactor * m" where 'MRD' is the minimum resolvable difference for the depth buffer (~1/(1<<16) or ~1/(1<<24)), 'm' is the approximated slope from the GL spec, and '2' is this magic number from the original i965 code dump that we deviate from the GL spec by because "it makes glean work" (except that it doesn't, because of some hilarity with 0.5 * approximately 2.0 != 1.0. go glean!). This clipper code for unfilled polygons, on the other hand, was doing "OffsetUnits * garbage + OffsetFactor * m", where garbage was MRD in the case of 16-bit depth visual (regardless the FBO's depth resolution), or 128 * MRD for 24-bit depth visual. This change just makes the unfilled polygons behavior match the WM's filled polygons behavior. Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Use the current drawbuffer's depth for polygon offset scale.Eric Anholt2013-06-261-1/+1
| | | | | | | There's no reason to care about the window system visual's depth for handling polygon offset in an FBO, and it could only lead to pain. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add perf debug for glCopyPixels() fallback checks.Eric Anholt2013-06-261-33/+39
| | | | | | | | | The separate function for the fallback checks wasn't particularly clarifying things, so I put the improved checks in the caller. (Note that the dropped _mesa_update_state() had already happened once at the start of the caller) Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add debug to INTEL_DEBUG=blorp describing hiz/blit/clear ops.Eric Anholt2013-06-263-0/+39
| | | | | | | | | | | | | I think we've all added instrumentation at one point or another to see what's being called in blorp. Now you can quickly get output like: Testing glCopyPixels(depth). intel_hiz_exec depth clear to mt 0x16d9160 level 0 layer 0 intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0 intel_hiz_exec hiz ambiguate to mt 0x16d9160 level 0 layer 0 intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0 Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Dump IR when fatally not compiling due to bad register spilling.Eric Anholt2013-06-261-1/+2
| | | | | | It should never happen, but it does, and at this point, you're going to _mesa_problem() and abort() (unless it's just in precompile). Give the developer something to look at.
* xmlpool/build: Make sure to set mo properlyNaohiro Aota2013-06-251-1/+1
| | | | | | | | | | Some shells does not set variables sequentially in a statement i.e. "a=X b=${a}" won't set "b" to "X" but empty value. This patch introduce ";" to make sure "mo" is set properly before "lang" assignment. Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=471302
* i965: Remove the rest of brw_update_draw_buffer().Eric Anholt2013-06-251-27/+5
| | | | | | | | | | | The last piece of code with an effect was flagging _NEW_BUFFERS. Only, that is already flagged from everything that calls this function: Mesa GL state updates flag it before even calling down into the driver, and the calls from the DRI2 window system framebuffer update path end up flagging it as part of the ResizeBuffers() hook. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop updating FBO state on drawbuffers change.Eric Anholt2013-06-251-8/+0
| | | | | | | | The computed fields are updated appropriately as part of the normal draw call path due to _NEW_BUFFERS being set. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop recomputing drawbuffer bounds on drawbuffer change.Eric Anholt2013-06-251-2/+0
| | | | | | | | | For winsys FBOs, the bounds are appropriately updated immediately upon _mesa_resize_framebuffer(). For user FBOs, they're updated as part of the normal draw path state update due to _NEW_BUFFERS having been flagged. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove _NEW_DEPTH state flagging on drawbuffers change.Eric Anholt2013-06-252-3/+1
| | | | | | | | Of the places noting a _NEW_DEPTH dependency, all were already checking for _NEW_BUFFERS if appropriate. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Stop doing special _NEW_STENCIL state flagging on drawbuffers.Eric Anholt2013-06-254-10/+5
| | | | | | | | 2/3 packets depending on Stencil._Enabled already checked for _NEW_BUFFERS, so just add _NEW_BUFFERS to the remaining one. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop flagging viewport/scissor change on drawbuffers change.Eric Anholt2013-06-251-3/+0
| | | | | | | | | The viewport (ctx->Viewport._WindowMap) doesn't change with drawable size changes, and we update scissor (ctx->DrawBuffer->_Xmin and friends) on _NEW_BUFFERS in things like brw_sf_state.c. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop flagging _NEW_POLYGON on drawbuffers change.Eric Anholt2013-06-251-5/+0
| | | | | | | | Things like brw_sf.c that need to know about orientation are already recomputing on _NEW_BUFFERS. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* radeon: Remove gratuitous custom framebuffer resize code.Eric Anholt2013-06-251-31/+0
| | | | | | | | | _mesa_resize_framebuffer(), the default value of the ResizeBuffers hook, already checks for a window system framebuffer and walks the renderbuffers calling AllocStorage(). Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Remove gratuitous custom framebuffer resize code.Eric Anholt2013-06-251-30/+6
| | | | | | | | | _mesa_resize_framebuffer(), the default value of the ResizeBuffers hook, already checks for a window system framebuffer and walks the renderbuffers calling AllocStorage(). Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove the Initialized field from framebuffers.Eric Anholt2013-06-255-8/+0
| | | | | | | | | | This existed to tell the core not to call GetBufferSize, except that even if you didn't set it nothing happened because nobody had a GetBufferSize. v2: Remove two more instances of setting the field (from Brian) Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove Driver.GetBufferSize and its callers.Eric Anholt2013-06-256-6/+0
| | | | | | | | Only the GDI driver set it to non-NULL any more, and that driver has a Viewport hook that should keep it limping along as well as it ever has. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Use shared code for converting shader targets to short strings.Eric Anholt2013-06-211-5/+4
| | | | | | | | We were duplicating this code all over the place, and they all would need updating for the next set of shader targets. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* glsl: Remove ir_print_visitor.h includes and usageEric Anholt2013-06-219-11/+2
| | | | | | | | | | | | | We have ir->print() to do the old declaration of a visitor and having the IR accept the visitor (yuck!). And now you can call _mesa_print_ir() safely anywhere that you know what an ir_instruction is. A couple of missing printf("\n")s are added in error paths -- when an expression is handed to the visitor, it doesn't print '\n' (since it might be a step in printing a whole expression tree). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* gen7: fix GPU hang on WebGL texture-size testJordan Justen2013-06-181-1/+1
| | | | | | | | | | | | | | | | | | When rendering to a texture with BaseLevel set, the miptree may be laid out such that BaseLevel is in level 0 of the miptree (to avoid wasting memory on unused levels between 0 and BaseLevel-1). In that case, we have to shift our render target's level down to the appropriate level of the smaller miptree. The WebGL test in combination with a meta code relating to glGenerateMipmap also triggered a similar failure scenario. This GPU hang regression was introduced by c754f7a8. Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65324 Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* intel: Remove unused IS_POWER_OF_TWO() macro.Eric Anholt2013-06-181-2/+0
| | | | | | The is_power_of_two() inline function has been used instead. Reviewed-by: Matt Turner <[email protected]>
* intel: Allow blorp CopyTexSubImage to nonzero destination slices.Eric Anholt2013-06-173-14/+9
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* intel: Allow blit CopyTexSubImage to nonzero destination slices.Eric Anholt2013-06-171-14/+9
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* intel: Directly implement blit glBlitFramebuffer instead of awkward reuse.Eric Anholt2013-06-173-70/+72
| | | | | | | | | | This gets us support for blitting to attachment types other than textures. v2: fix up comments from review by Kenneth. Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Paul Berry <[email protected]>
* intel: Move XRGB->ARGB blit logic into intel_miptree_blit().Eric Anholt2013-06-174-100/+63
| | | | | | | | Now any caller (such as glCopyPixels()) can benefit from it, and it only changes the correct subset of the destination instead of a whole teximage. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* intel: Fix Y tiling support for glCopyTexSubImage's alpha override.Eric Anholt2013-06-171-4/+4
| | | | | | | | | | | Apparently we don't have any piglit tests for this, because it would have assertion failed in a debug build, or just rendered wrong in a non-debug build if the destination wasn't covering whole tiles. v2: Use the new macros. Reviewed-by: Paul Berry <[email protected]> (v1) Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* intel: Make batch macros for doing BCS_SWCTRL setup.Eric Anholt2013-06-171-37/+47
| | | | | | | | | | | | | We're going to add more BCS_SWCTRL setup instances soon, and you have to be careful to have the set and restore atomic with the rendering that's done, so that our state doesn't leak out to other rendering processes. v2: Rewrite the patch to have batch begin/advance macros so that magic numbers don't get sprinkled around (and so you don't mix up your do-I-need-to-reset vs what-do-I-reset-to logic, which I nearly did in the next patch when first writing it) Acked-by: Kenneth Graunke <[email protected]>
* mesa: Hide weirdness of 1D_ARRAY textures from Driver.CopyTexSubImage().Eric Anholt2013-06-174-10/+18
| | | | | | | | | | | | | | | | | Intel had brokenness here, and I'd like to continue moving Mesa toward hiding 1D_ARRAY's ridiculousness inside of the core, like we did with MapTextureImage. Fixes copyteximage 1D_ARRAY on intel. There's still an impedance mismatch in meta when falling back to read and texsubimage, since texsubimage expects coordinates into 1D_ARRAY as (width, slice, 0) instead of (width, 0, slice). v2: Fix offset of scanline reads from the source. (Thanks Brian!), replace dd.h comment with Paul's text and replace early exit with an assert. Reviewed-by: Brian Paul <[email protected]> (v1) Reviewed-by: Kenneth Graunke <[email protected]> (v1) Reviewed-by: Paul Berry <[email protected]> (v1)
* i965: Assume flexible hardware primitive restart exists in the future.Kenneth Graunke2013-06-141-1/+1
| | | | | | Primitive restart with an arbitrary cut index was first supported as of Haswell. It's very doubtful that they'd take that away in future hardware, so we may as well alter the check now.
* i965: Shrink Gen5 VUE map layout to be the same as Gen4.Chris Forbes2013-06-166-40/+7
| | | | | | | | | | | | | | | | | | | The PRM suggests a larger layout, mostly to support having gl_ClipDistance[] somewhere predictable for the fixed-function clipper -- but it didn't actually arrive in Gen5. Just use the same layout for both Gen4 and Gen5. No Piglit regressions. Improves performance in CS:S Video Stress Test by ~3%. V2: - Remove now-useless function for determining the SF URB read offset - Remove now-unused BRW_VARYING_SLOT_POS_DUPLICATE Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Implement 16-wide math on G45 and Ironlake.Kenneth Graunke2013-06-162-0/+28
| | | | | | | | [chrisf:] Improves performance in CS:S video stress test by about 2%. No piglit regressions on Ironlake. Reviewed-by: Chris Forbes <[email protected]>
* mesa: fix OES_EGL_image_external being partially allowed in the core profileMarek Olšák2013-06-131-1/+2
| | | | Reviewed-by: Chad Versace <[email protected]>
* i965/gen7: Enable support for fast color clears.Paul Berry2013-06-121-0/+20
| | | | | | | | | | | This patch adds code to place mcs_state into INTEL_MCS_STATE_RESOLVED for miptrees that are capable of supporting fast color clears. This will have no effect on buffers that don't undergo a fast color clear; however, for buffers that do undergo a fast color clear, an MCS miptree will be allocated (at the time of the first fast clear), and will be used thereafter. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Disable fast color clears on shared regions.Paul Berry2013-06-124-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | In certain circumstances the memory region underlying a miptree is shared with other miptrees, or with other code outside Mesa's control. This happens, for instance, when an extension like GL_OES_EGL_image or GLX_EXT_texture_from_pixmap extension is used to associate a miptree with an image existing outside of Mesa. When this happens, we need to disable fast color clears on the miptree in question, since there's no good synchronization mechanism to ensure that deferred clear writes get performed by the time the buffer is examined from the other miptree, or from outside of Mesa. Fortunately, this should not be a performance hit for most applications, since most applications that use these extensions use them for importing textures into Mesa, rather than for exporting rendered images out of Mesa. So most of the time the miptrees involved will never experience a clear. v2: Rework based on the fact that we have decided not to use an accessor function to protect access to the region. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Resolve color buffers when necessary.Paul Berry2013-06-127-3/+37
| | | | | | | | | | | | | | | | Resolve color buffers that have been fast-color cleared: 1. before texturing from the buffer (brw_predraw_resolve_buffers()) 2. before using the buffer as the source in a blorp blit (brw_blorp_blit_miptrees()) 3. before mapping the buffer's miptree (intel_miptree_map_raw(), intel_texsubimage_tiled_memcpy()) 4. before accessing the buffer using the hardware blitter (intel_miptree_blit(), do_blit_bitmap()) v2: Rework based on the fact that we have decided not to use an accessor function to protect access to the region. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Ensure that front/back buffers are fast-clear resolved.Paul Berry2013-06-123-12/+15
| | | | | | | | | | | | We already had code in intel_downsample_for_dri2_flush() for downsampling front and back buffers when multisampling was in use. This patch extends that function to perform fast color clear resolves when necessary. To account for the additional functionality, the function is renamed to simply intel_resolve_for_dri2_flush(). Reviewed-by: Eric Anholt <[email protected]>
* i965/blorp: Write blorp code to do render target resolves.Paul Berry2013-06-126-0/+96
| | | | | | | | | | | | | | | | | | | This patch implements the "render target resolve" blorp operation. This will be needed when a buffer that has experienced a fast color clear is later used for a purpose other than as a render target (texturing, glReadPixels, or swapped to the screen). It resolves any remaining deferred clear operation that was not taken care of during normal rendering. Fortunately not much work is necessary; all we need to do is scale down the size of the rectangle primitive being emitted, run the fragment shader with the "Render Target Resolve Enable" bit set, and ensure that the fragment shader writes to the render target using the "replicated color" message. We already have a fragment shader that does that (the shader that we use for fast color clears), so for simplicity we re-use it. Reviewed-by: Eric Anholt <[email protected]>
* i965/blorp: Expand clear class hierarchy to prepare for RT resolves.Paul Berry2013-06-122-25/+35
| | | | | | | | | | | | | | The fragment shaders that to do color clears will be re-used to perform so-called "render target resolves" (the resolves associated with fast color clears). To prepare for that, this patch expands the class hierarchy for blorp params by adding brw_blorp_const_color_params (which will be used for all blorp operations where the fragment shader outputs a constant color). Some other data structures and functions were also renamed to use "const_color" nomenclature where appropriate. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Implement fast color clear operation in BLORP.Paul Berry2013-06-129-14/+240
| | | | | | | | | | | | | | | | | | Since we defer allocation of the MCS miptree until the time of the fast clear operation, this patch also implements creation of the MCS miptree. In addition, this patch adds the field intel_mipmap_tree::fast_clear_color_value, which holds the most recent fast color clear value, if any. We use it to set the SURFACE_STATE's clear color for render targets. v2: Flag BRW_NEW_SURFACES when allocating the MCS miptree. Generate a perf_debug message if clearing to a color that isn't compatible with fast color clear. Fix "control reaches end of non-void function" build warning. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Create helper functions for single-sample MCS buffers.Paul Berry2013-06-122-0/+128
| | | | Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Set up MCS in SURFACE_STATE whenever MCS is present.Paul Berry2013-06-123-5/+7
| | | | | | | | | | | | | | | On Gen7+, MCS buffers are used both for compressed multisampled color buffers and for "fast clear" of single-sampled color buffers. Previous to this patch series, we didn't support fast clear, so we only used MCS with multisampled bolor buffers. As a first step to implementing fast clears, this patch modifies the code that sets up SURFACE_STATE so that it configures the MCS buffer whenever it is present, regardless of whether we are multisampling or not. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Create an enum for keeping track of fast color clear state.Paul Berry2013-06-126-0/+104
| | | | | | | | | | | | | This patch includes code to update the fast color clear state appropriately when rendering occurs. The state will also need to be updated when a fast clear or a resolve operation is performed; those state updates will be added when the fast clear and resolve operations are added. v2: Create a new function, intel_miptree_used_for_rendering() to handle updating the fast color clear state when rendering occurs. Reviewed-by: Eric Anholt <[email protected]>
* intel: Conditionally compile mcs-related code for i965 only.Paul Berry2013-06-122-1/+9
| | | | | | | | | This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915 (pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there is no need for this field in the i915 driver). This should make it a bit easier to implement fast color clears without undue risk to i915. Reviewed-by: Eric Anholt <[email protected]>
* intel: Keep region name in intel_miptree_create_for_dri2_buffer().Paul Berry2013-06-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | When processing a buffer received from the X server, intel_process_dri2_buffer() examines intel_region::name to determine whether it's received a brand new buffer, or the same buffer it received from the X server the last time it made a request. However, this didn't work properly, because in the call to intel_miptree_create_for_dri2_buffer(), we create a fresh intel_region object to represent the buffer, and this was causing us to forget the buffer's previous name. This patch fixes things by copying over the region name when creating the fresh intel_region object. At the moment, this is just a minor performance optimization. However, when fast color clears are added, it will be necessary to ensure that the fast color clear state for a buffer doesn't get discarded the next time we receive that buffer from the X server. Reviewed-by: Eric Anholt <[email protected]>
* i965: Emit the depth/stencil state pointer directly, not via atoms.Kenneth Graunke2013-06-117-80/+18
| | | | | | | | | | | | | | | | | | | | | See two commits ago for the rationale. This allows us to delete the whole gen7_cc_state.c file. This does move these commands before the depth stall flushes from brw_emit_depthbuffer, which may be a problem. The documentation for 3DSTATE_DEPTH_BUFFER mentions that depth stall flushes are required before changing any depth/stencil buffer state, but explicitly lists 3DSTATE_DEPTH_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_CLEAR_PARAMS. It does not mention this particular packet (_3DSTATE_DEPTH_STENCIL_STATE_POINTERS). No observed Piglit regressions on Sandybridge or Ivybridge. Together with the last two commits, this makes a cairo-gl benchmark faster by 0.324552% +/- 0.258355% on Ivybridge. No statistically significant change on Sandybridge. (Thanks to Eric for the numbers.) Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Emit the CC state pointer directly rather than via atoms.Kenneth Graunke2013-06-115-30/+18
| | | | | | See the previous commit for the rationale. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Emit the BLEND_STATE pointer directly rather than via atoms.Kenneth Graunke2013-06-115-30/+18
| | | | | | | | | | | | | | | | | | | | | | | | Previously, we would: 1. Emit the new indirect state. 2. Flag CACHE_NEW_BLEND_STATE. 3. Rely on later state atoms to notice CACHE_NEW_BLEND_STATE and emit a pointer to the new indirect state. This is rather cumbersome: it requires two state atoms instead of one, and there's a strict ordering dependency in the list. Plus, the code gets spread across two functions (or even files in the case of Gen7+). Gen7+ has a packet to update just the blend state pointer, so it makes a lot of sense to simply emit that right away. Gen6 has a combined packet which updates blending, the color calculator, and depth/stencil state; however, each can still be modified independently. This drops the Gen6 micro-optimization where we tried to only emit one packet that changed all three states. State updates are pretty cheap. CACHE_NEW_BLEND_STATE is no longer necessary, so drop it. Signed-off-by: Kenneth Graunke <[email protected]>
* Revert "i965: Disable unused pipeline stages once at startup on Gen7+."Kenneth Graunke2013-06-113-6/+13
| | | | | | | | | | This reverts commit 6c966ccf07bcaf64fba1a9b699440c30dc96e732. Apparently causes GPU hangs. Conflicts: src/mesa/drivers/dri/i965/brw_state.h src/mesa/drivers/dri/i965/brw_state_upload.c
* i965/vs: Avoid the MUL/MACH/MOV sequence for small integer multiplies.Eric Anholt2013-06-101-13/+37
| | | | | | | | | | | | | | | We do a lot of multiplies by 3 or 4 for skinning shaders, and we can avoid the sequence if we just move them into the right argument of the MUL. On pre-IVB, this means reliably putting a constant in a position where it can't be constant folded, but that's still better than MUL/MACH/MOV. Improves GLB 2.7 trex performance by 0.788648% +/- 0.23865% (n=29/30) v2: Fix test for pre-sandybridge. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> (v1)
* i965/vs: Allow copy propagation into MUL/MACH.Eric Anholt2013-06-101-2/+4
| | | | | | | | | | | This is a trivial port of 1d6ead38042cc0d1e667d8ff55937c1e32d108b1 from the FS. No significant performance difference on trex (misplaced the data, but it was about n=20). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 08:46:49 +0000