Am Tuesday 22 September 2009 23:25:09 schrieb Pauli Nieminen:
> Too bad GPU reset is already now stopping this use case while it doesn't
> protect user from possible attack causing multiple GPU reset in row. So
> this long rendering operation blocking GPU is more like scheduler or mesa
> bug that i
Am Tuesday 22 September 2009 21:13:47 schrieb Pauli Nieminen:
> Hi!
>
> I have been thinking GPU reset as possible DoS attack from
> user-space.Problem here is that display doesn't work anymore at all if
> attacker chooses to run a application that constantly causes GPU hang. It
> would be of cours
ont buffer rendering and reading works correctly.
Signed-off-by: Nicolai Hähnle
---
src/mesa/state_tracker/st_framebuffer.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_framebuffer.c
b/src/mesa/state_tracker/st_framebuffer.c
in
ent-Transfer-Encoding: 8bit
Signed-off-by: Nicolai Hähnle
---
src/mesa/state_tracker/st_cb_fbo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index a966028..aad8493 100644
--- a/src/mesa/state_trac
Certain tests (e.g. piglit's crossbar) crash because they do (possibly
somewhat weird things) with glReadBuffer().
What happens is this:
- Context gets set up, made current
- Stuff gets rendered
- glReadBuffer() is called to change the read buffer
- glReadPixels() crashes because now ctx->ReadBuf
f state data caused a crash due to double-free on destruction
of context, because a variable wasn't correctly null'ed out.
Signed-off-by: Nicolai Hähnle
---
src/mesa/drivers/dri/r300/r300_ioctl.c | 16 +++---
src/mesa/drivers/dri/r300/r300_state.c | 18 +++---
Hi,
Am Donnerstag 12 Februar 2009 06:29:27 schrieb Dave Airlie:
> So I have a goal to get a radeon driver that works on a bufmgr and that
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
> work.
Yay!
[snip]
> So far I've been working on getting the legacy buffer/command c
Am Donnerstag 12 Februar 2009 15:10:11 schrieb Roland Scheidegger:
> Compressed textures also seem to be broken, since they'll raise a FPE:
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread -1480239424 (LWP 11180)]
> 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48,
Am Donnerstag 25 September 2008 01:44:49 schrieb Dieter Nützel:
> Need it badly for my favored xscreensaver mode noof or KDE's 'Euphorie'...
>
> progs/redbook> xscreensaver-demo
> *WARN_ONCE*
> File r300_render.c function r300Fallback
Hi,
testing the r300-bufmgr has revealed that the driDestroyDrawable is never
called in very simple applications such as glxinfo or glxgears. This
obviously causes a number of memory leaks. Unfortunately, I don't really
understand that part of the code yet, but I have confirmed that the problem
Am Montag 11 August 2008 02:53:44 schrieb Stephane Marchesin:
> On 8/2/08, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> > I might be totaly wrong so feel free to ignore these. I got the feeling
> > that the user test base on linux kernel is far bigger than ours. Also
> > i think that our test user
Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen:
> > I'm having troubles obtaining GLX visual with accumulation buffers. It
> > happens only on Fedora 9. Attached is glxinfo log.
> > Problem never appears with fglrx drivers, but as you know it's not
> > available for FC9.
> >
> > I'm really lo
Am Mittwoch 06 August 2008 02:53:23 schrieb [EMAIL PROTECTED]:
> I've been working on a port of DRM for Syllable.? Syllable doesn't support
> drivers (or kernel modules) that are on the same level of abstraction &
> communicate with each other.? For example our sound card drivers can't
> communicat
Am Freitag 25 Juli 2008 12:12:59 schrieb Jerome Glisse:
> This looks like usual engine lockup followed by CP lockup so
> that DMA buffer age never get written and we run out of DMA
> buffer thus freelist failing in infinite loop.
>
> I think we now know all the reason why we lockup, while a
> fix c
Am Sonntag 08 Juni 2008 03:57:48 schrieb Dave Airlie:
> > Hmm, the radeon_cp_idle() should purge the destination cache (and wait
> > for it too, including checking the DC_BUSY bit).
> > At least the r200 driver has a comment in r200SpanRenderStart (including
> > a dodgy workaround) which sure looks
Hi,
I'm currently trying to figure out why glean/texCube reproducably fails on my
R420. That test basically has a number of sections that look like this
loop(..) {
render();
loop(..) {
glReadPixels(..);
check_values();
}
}
The outer loop continuously overwrites the s
16 matches
Mail list logo
