- 15 7月, 2009 3 次提交
-
-
由 Dave Airlie 提交于
Userspace sends us a special relocation type to sync video/exa to vlines to avoid tearing, this deals with the relocation in the kernel, it picks the correct crtc and avoids issues where crtcs are disabled. This version also parses the wait until to make sure it isn't trying to do anything evil. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Normally we are free to place VRAM where we want in the GPUs memory address space, however on IGP chips the VRAM is actual RAM, and no special translation or aperture is used inside the GPU MC. So when you move the VRAM aperture away from the TOM register, you actually move it into main memory and can trash things quite badly. This commit makes the code respect the TOM location for MC_FB_LOCATION. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
1. rv370 can accept 40-bit addresses - also at 24-bit shift not 4 bits 2. rs480 table can be in 40-bit space. - 4 bit shift for top 8 bits 3. rs480 table entries can be in 40-bit space. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 6月, 2009 3 次提交
-
-
由 Jerome Glisse 提交于
For security purpose we want to make sure the userspace process doesn't access memory beyond buffer it owns. To achieve this we need to check states the userspace program. For color buffer and zbuffer we check that the clipping register will discard access beyond buffers set as color or zbuffer. For vertex buffer we check that no vertex fetch will happen beyond buffer end. For texture we check various texture states (number of mipmap level, texture size, texture depth, ...) to compute the amount of memory the texture fetcher might access. The command stream checking impact the performances so far quick benchmark shows an average of 3% decrease in fps of various applications. It can be optimized a bit more by caching result of checking and thus avoid a full recheck if no states changed since last check. Note that this patch is still incomplete on checking side as it doesn't check 2d rendering states. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Michel Dänzer 提交于
Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Its quite valid to have VRAM < aperture size. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 6月, 2009 1 次提交
-
-
由 Jerome Glisse 提交于
Add kernel modesetting support to radeon driver, use the ttm memory manager to manage memory and DRM/GEM to provide userspace API. In order to avoid backward compatibility issue and to allow clean design and code the radeon kernel modesetting use different code path than old radeon/drm driver. When kernel modesetting is enabled the IOCTL of radeon/drm driver are considered as invalid and an error message is printed in the log and they return failure. KMS enabled userspace will use new API to talk with the radeon/drm driver. The new API provide functions to create/destroy/share/mmap buffer object which are then managed by the kernel memory manager (here TTM). In order to submit command to the GPU the userspace provide a buffer holding the command stream, along this buffer userspace have to provide a list of buffer object used by the command stream. The kernel radeon driver will then place buffer in GPU accessible memory and will update command stream to reflect the position of the different buffers. The kernel will also perform security check on command stream provided by the user, we want to catch and forbid any illegal use of the GPU such as DMA into random system memory or into memory not owned by the process supplying the command stream. This part of the code is still incomplete and this why we propose that patch as a staging driver addition, future security might forbid current experimental userspace to run. This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX (radeon up to X1950). Works is underway to provide support for R6XX, R7XX and newer hardware (radeon from HD2XXX to HD4XXX). Authors: Jerome Glisse <jglisse@redhat.com> Dave Airlie <airlied@redhat.com> Alex Deucher <alexdeucher@gmail.com> Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-