sarnex_ has quit [Read error: Connection reset by peer]
yuq825 has joined #dri-devel
youmukonpaku133 has quit [Read error: Connection reset by peer]
Guest7648 has quit [Ping timeout: 480 seconds]
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
benjaminl has joined #dri-devel
sarnex_ has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
tristan has joined #dri-devel
tristan is now known as Guest7653
benjaminl has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
sarnex_ has quit []
sarnex has joined #dri-devel
Zopolis4 has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
simon-perretta-img__ has joined #dri-devel
a-865 has joined #dri-devel
rgallaispou has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
vaibhav_malik has joined #dri-devel
vaibhav_malik has quit [Quit: Leaving]
vaibhav_malik has joined #dri-devel
bmodem has joined #dri-devel
Guest7653 has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<mareko>
zmike: after varying linking and before uniform/UBO linking
<mareko>
zmike: don't set PIPE_CAP_CULL_DISTANCE_NOCOMBINE or any CAPs that mess with IO
bmodem has joined #dri-devel
Company has quit [Quit: Leaving]
bmodem has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
itoral has joined #dri-devel
yuq825 has quit [Ping timeout: 480 seconds]
vaibhav_malik has quit [Remote host closed the connection]
vaibhav_malik has joined #dri-devel
jkrzyszt_ has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
tristan has joined #dri-devel
tristan is now known as Guest7662
junaid has joined #dri-devel
vaibhav_malik has quit [Quit: Leaving]
mvlad has joined #dri-devel
vliaskov__ has joined #dri-devel
schaeffer_ has joined #dri-devel
schaeffer has quit [Ping timeout: 480 seconds]
vliaskov_ has joined #dri-devel
frieder has joined #dri-devel
rz_ has joined #dri-devel
rz has quit [Ping timeout: 480 seconds]
vliaskov__ has quit [Ping timeout: 480 seconds]
Guest7662 has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tursulin has joined #dri-devel
crabbedhaloablut has joined #dri-devel
yuq825 has joined #dri-devel
fab has joined #dri-devel
sima has joined #dri-devel
pcercuei has joined #dri-devel
fab has quit [Quit: fab]
sarahwalker has joined #dri-devel
rmckeever has quit [Quit: Leaving]
swalker_ has joined #dri-devel
dviola has quit [Quit: WeeChat 4.0.2]
swalker_ is now known as Guest7673
sarahwalker has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
dviola has joined #dri-devel
aravind has joined #dri-devel
Zopolis4 has quit [Quit: Connection closed for inactivity]
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
puck_ has quit [Quit: -w-]
puck_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
vaibhav_malik has joined #dri-devel
tristan has joined #dri-devel
tristan is now known as Guest7675
<zmike>
mareko: good point
<zmike>
I assume your gallium rbs count for all of gallium?
<lumag>
jani, can I try to gain your attention at https://patchwork.freedesktop.org/series/120395/ ? The series seems to have all acks / reviews. Since it touches drm-core and intel (and usb/typc), what would be the best way to merge it?
a-865 has quit [Ping timeout: 480 seconds]
vaibhav_malik has quit [Quit: Leaving]
godvino has joined #dri-devel
cmichael has joined #dri-devel
sgruszka has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
jkrzyszt_ has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
Zopolis4 has joined #dri-devel
junaid has joined #dri-devel
junaid has quit []
junaid has joined #dri-devel
itoral has quit [Quit: Leaving]
<zmike>
mareko: hm it doesn't seem like PIPE_CAP_CULL_DISTANCE_NOCOMBINE should affect this? my point was more that it's possible to indirectly access clip/cull distance, which lowered io very much does not handle
<zmike>
having to work around it with io to temps is annoying
junaid has quit [Remote host closed the connection]
heat has joined #dri-devel
enick_646 has quit []
kts has joined #dri-devel
Guest7675 has quit [Ping timeout: 480 seconds]
<alyssa>
annoying for "difficulty to code reasons" or annoying for "it makes the generated NIR worse"
<alyssa>
?
<alyssa>
for the latter, IDK, the driver will presumably do this anyway regardless of what spir-v you feed in
lplc has quit [Quit: WeeChat 3.8]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
Namarrgon has quit [Ping timeout: 480 seconds]
hramrach has quit [Ping timeout: 480 seconds]
<cwabbott>
zmike: the hidden lore I've learned is that you need to call nir_lower_indirect_derefs for compact variables
<cwabbott>
we accidentally added a dependency on that even though drivers don't normally need to use it
<cwabbott>
see ir3_nir_lower_io_to_temporaries()
aravind has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
MajorBiscuit has joined #dri-devel
yyds has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
godvino has quit [Quit: WeeChat 3.6]
kts has quit [Quit: Leaving]
heat_ has quit [Remote host closed the connection]
<mriesch>
mripard: sorry to bug you, but do you have a minute to discuss this overscan thing here?
fxkamd has quit []
aravind has joined #dri-devel
<mripard>
sure
benjaminl has quit [Ping timeout: 480 seconds]
<mriesch>
mripard: cool. so in general the display server should set the overscan/margins according to user input/configuration/etc?
<mripard>
yeah, mostly because in the general case the kernel won't be able to tell how much of the panel is hidden
<mriesch>
ok, could you point me to an example how this can be accomplished with $DISPLAY_SERVER?
<mripard>
also, part of it is based on context: if you are drawing a UI, then you don't want to have anything missing, if you're playing a video and drawing on the visible area, then whether or not you want to allow the edges to be hidden or if you'd rather rescale it is not something the kernel can figure out
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
<mriesch>
mripard: i must admit that i still cannot see the advantages here. i can see that for the case of a display connected via hdmi (or even worse, vga) the kernel cannot figure out the size of the active area.
<mriesch>
but for the case of a specially manufactured lcd that is built into some embedded device, we can be pretty sure that we know the size of the active area.
<mripard>
it's not the active area though, it's something smaller than the active area
<mriesch>
hm, how is this area called anyway? "effective"? "visible"?
<mripard>
and you then expose to the user-space a mode, but will actually display something smaller than what you claimed to support, without telling anyone
<mripard>
visible works for me :)
<zamundaaa[m]>
Yeah, please don't do stuff behind the compositors back
<mripard>
I guess that's my main concern: you have a mode, and then you choose to crop that using arbitrary numbers without telling it
<zamundaaa[m]>
If you want to have some overscan value set by default, you could expose a new property similar to "panel orientation" and then patch compositors to deal with it explicitly
Namarrgon has quit [Ping timeout: 480 seconds]
<mriesch>
wait a sec, the display driver exposes exactly the visible area (240x280 in my case, in contrast to the 240x320 that the display controller could handle)
<mripard>
if you don't want to deal with the dynamic stuff for now and would rather leave that out of Weston since it's fixed, that's fine for me
<mripard>
but we should expose that using properties with whatever we crop it with
<mriesch>
ok, let me try to understand the advantages of this approach
Haaninjo has joined #dri-devel
<mriesch>
you said above that depending on the context applications could decide whether to optimize their content to e.g. a standard 4:3 format or to an off-standard format (visible area)
<mripard>
I guess the main advantage, really, is that we're not doing anything behind anyone's back
<mriesch>
how can a (e.g., qt) application find out what it should do?
<sima>
mriesch, is there no way you can hide this in the kernel driver for your lcd?
<sima>
if it's all perfectly known upfront at least this should be doable with adjusting the mode int atomic_check code
<sima>
and also adjusting the modes you report on the lcd panel in get_modes
<sima>
(callback names from memory, might have gotten them wrong)
<mripard>
sima: that's pretty much what he was doing
<sima>
imo the overscan stuff really should be for analog TV, and stuff that for whatever silly reasons works like analog TV overscan
<mriesch>
sima: v2 of my patch series introduced a compatible for my custom lcd, the driver then exposes the visible area as a mode to user space and applies the corresponding register values to the display controller
<sima>
yeah that looks reasonable (without checking all the details and everything)
<sima>
it would be more funky if we can only adjust in the scanout engine (and so that engine would need to scan out more stuff than the drm_framebuffer has)
<mripard>
I don't see why we should treat something pretty much identical in two different ways
mbrost_ has joined #dri-devel
<sima>
but this just looks like a somewhat special mode with enlarge inactive areas ...
<sima>
mripard, because the analog stuff is hopeless non-configurable without a user looking at the screen
<sima>
whereas this one here really should Just Work
<mripard>
especially since the work is fairly simple in the first place
<sima>
so analog overscan needs properties wired all the way to a desktop tool
<sima>
this here ... not
<mripard>
I kind of disagree, it's not just analog TV. HDMI has that too
<sima>
yeah, "stuff that for hysterical reasons works like analog TV"
<mripard>
and like I said, let's assume with have a panel with 10 pixels margins in each direction
<sima>
we try real hard to drive hdmi in the non-bonkers non-tv-compat mode
bmodem has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<mripard>
do we really want to rescale a fixed resolution content like video every frame?
<mripard>
I'd rather drop the margins and send the picture as is .
<sima>
mripard, I'm confused
<sima>
there's no rescaling going on with this lcd
<sima>
it's just a 280x240 lcd with a bit a funky modeline
<mripard>
even more so on a super slow SPI device
<sima>
you mean that we have to transfer lines that aren't visible?
<mriesch>
mripard: "super slow SPI device" -> the data is not transmitted via spi, if this is what you mean. there is an rgb interface
<mripard>
no, I mean, let's assume we have an active 480p panel, play a 480p video, but the active size is 20 pixels smaller. You'll still need to rescale
<mripard>
not on the device itself
<mripard>
but you'll have to do it anyway
<mripard>
mriesch: my bad :)
<sima>
how is that any different from trying to display 480p content on a 320p screen?
<sima>
you got to either cut or rescale
<sima>
and it's kind up to the app what it wants to do
<sima>
mripard, it's a drm_panel driver, not a drm/tiny driver :-)
<mripard>
except you don't have to in this case
<sima>
mripard, why?
<mripard>
you could just drop the margins
<sima>
uh
<sima>
you can
<sima>
drm_framebuffer has offset property
<sima>
and size
<sima>
so you can take your 4k buffer and scan out a 320p piece of it
<sima>
assuming your crtc can
<mripard>
some part of it won't be visible anymore, but that might be fine
<sima>
and we've become fairly good at using the right helpers to make that work as often as doable
<sima>
mripard, since we're talking a bit past each another, can you give an end-to-end example of what you want to do?
<sima>
(and suspect it wont be possible anymore with mriesch 's approach)
<sima>
end-to-end = gem bo all the way to how it shows up on the screen
<mripard>
I'm not sure we're talking past each other
<mripard>
if you feel like it works, then I won't stand in the way
<sima>
it seemed a bit like that to me ...
<sima>
mripard, maybe the other way round, I really don't like the overscan properties
<sima>
but the hw is crap enough that we cannot do better
<mripard>
I still don't get why we're doing something different in two different context for the same issue
<mripard>
but I guess we can always fix later on if it proves to be an issue
<sima>
anywhere were we know the exact overscan, we should adjust modes instead imo
<sima>
also for hdmi, drivers should try really hard to use the compute hdmi modes, where overscan should not be an issue
<sima>
*compute hdmi modes
<sima>
so that at least with hdmi this issue is gone (minus a few very old early and very crappy hdmi TVs)
<sima>
iirc vsyrjala has probably spent the most amount of screaming for this, maybe we need more "create the right hdmi infoframes" helpers, dunno
mbrost_ has quit [Ping timeout: 480 seconds]
<sima>
mripard, at that point analog overscan is left, and with those screens people just didn't care that much about really seeing everything
<mripard>
it still happens with my current TV (except if you label the input right), so it's very much happening :)
<sima>
mripard, intel driver?
<mripard>
vc4 at the very least, I don't remember if I checked with i915
<sima>
iirc the infoframe dance is very annoying, and sometimes it also depends upon which mode you pick (i.e. how much overscan, not the active area)
glennk has quit [Read error: Connection reset by peer]
bgs has joined #dri-devel
glennk has joined #dri-devel
<sima>
mripard, "label the input right" like some config item in your TV's menu?
<mripard>
yes
<mripard>
you have like 5 labels to tell which input is what
<mripard>
and only if it's the "PC" label the overscan margins are not there anymore
<mripard>
great UX
<sima>
ugh
<sima>
there's no "auto"?
<mripard>
default has the margins
<mripard>
and there's no auto iirc, I haven't checked for a while
<sima>
yeah, because by default like most hdmi modes are overscanned, unless you send the right infoframes
<sima>
if there's no overscan by default for most hdmi modes, your TV is not actually hdmi compliant
Danct12 has quit [Quit: A-lined: User has been AVIVA lined]
<sima>
yeah so from a quick look, unless you hand-roll a lot of code, only i915 gets all the infoframe stuff right enough
<sima>
iirc you absolutely have to fill in VIC and the content type or it's busted
<sima>
intel_hdmi_compute_config() bottom end has it all
<sima>
probably don't need the drm and gcp infoframes
kzd has joined #dri-devel
<sima>
all the others you need or some tv somewhere gets very confused
<sima>
(we should probably have more ready-made helpers that just dtrt since it's a bunch of typing)
<mriesch>
sima: ...going back to the plain and easy (mostly) world of embedded lcd's: if my approach looks reasonable to you, could you state your approval on the mailing list please? :-)
<sima>
mriesch, usually here an a-b: me (in principle, not any details) should be enough ...
<sima>
but I'll reply with a summary on-list
<mriesch>
sima: merci vielmols!
<sima>
gärn gscheh
<sima>
typed and sent
<mriesch>
mripard: thanks a lot for your time -- i guess we can move the discussion back to the list
<mripard>
well, I'm mostly sorry for wasting your time
<mripard>
but you're welcome I guess :)
Danct12 has joined #dri-devel
<sima>
mripard, mriesch maybe we should augment the docs in this area? not sure where exactly, maybe in the overscan property docs?
<mriesch>
mripard: well i can only guess what the correct path forward is so i need the feedback from you guys. no wasted time at all
<mriesch>
sima: as a newbie it was quite hard to find any docs describing overscan. it seems i am still missing the big picture here
Zopolis4 has quit [Quit: Connection closed for inactivity]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
mbrost has joined #dri-devel
i509vcb has joined #dri-devel
<zmike>
with explicit io, is a 64bit type supposed to emit component=1 or component=2 for the second component of a dvec2 ?
<zmike>
cc jenatali maybe
<jenatali>
I don't remember off the top of my head
<zmike>
it seems like I can get both
<zmike>
which is weird
<jenatali>
and I think the answer might be different for VS inputs vs interpolants
<zmike>
these are outputs
<zmike>
both vs stage
djbw has quit [Read error: Connection reset by peer]
<pendingchaos>
"explicit io" = lowered IO intrinsics (nir_intrinsic_store_output/etc), as opposed to derefs?
<pendingchaos>
I think the component was in (32/16-bit) components of the vec4 slot
<zmike>
so
<jenatali>
That does seem weird
<zmike>
I assumed it was component of the vec4 slot too
<jenatali>
Yeah my expectation would've been 2
<zmike>
and yet
<zmike>
pendingchaos: yes lowered io
<pendingchaos>
nir_lower_io_lower_64bit_to_32 is written as if component was of the vec4 slot
<pendingchaos>
which is what I usually look at because I always forget this
<zmike>
ok great
<zmike>
so I'll just hammer in something to fix this
djbw has joined #dri-devel
benjaminl has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
Guest7673 has quit [Remote host closed the connection]
Namarrgon has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
a-865 has joined #dri-devel
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
a-865 has quit [Remote host closed the connection]
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
angerctl has joined #dri-devel
rasterman has quit [Read error: Connection reset by peer]
jkrzyszt_ has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
yyds has quit [Remote host closed the connection]
angerctl has quit [Ping timeout: 480 seconds]
a-865 has joined #dri-devel
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
mort_ has joined #dri-devel
<mort_>
Here's a fun one: DRM is leaking a drm_crtc_commit every frame when using the MSM DRM driver. I'm waist deep in kernel code trying to figure out why the refcount never drops to 0
<mort_>
I've gathered stack traces of every get and put for a particular commit: https://p.mort.coffee/DVX, but I'm having trouble understanding exactly how this old state and new state stuff fits together so I'm having a hard time cancelling out gets and puts to find which get lacks a corresponding put
mbrost has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
a-865 has quit [Quit: ChatZilla 0.17b1 [SeaMonkey 2.53.17/20230610105000]]
junaid has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
DottorLeo has joined #dri-devel
DottorLeo has quit [Quit: Konversation terminated!]
bmodem has quit [Ping timeout: 480 seconds]
<italove>
what's the process to getting commits that were already-merged without "cc: mesa-stable" pulled into stable? I forgot to add the tag on !10747
<karolherbst>
open an MR agains the staging branch
<italove>
against which one? this is a fix that could go back quite a while, is it fine to open an MR against let's say, staging/21.2 ?
<karolherbst>
21.2 is end of life
<karolherbst>
only really makes sense for release branches with upcoming minor releases
FireBurn has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
rcf1 has quit []
junaid has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
mvlad has quit [Remote host closed the connection]
a-865 has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
crabbedhaloablut has quit []
mbrost has joined #dri-devel
mbrost__ has joined #dri-devel
bgs has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
<robclark>
mort_: hmm, seems like that is something that should have shown up with with kmemleak? Although possible it is a more recent issue or whatever introduced the leak wasn't backport to v5.15 prod kernel
<mort_>
robclark: it does show up in kmemleak, every frame shows a 256 size object leaked >_>
<mort_>
from the kmalloc-256 slab allocator
<airlied>
robclark: btw can you or someone else in msm land talk a look at porting msm to gpuva mgr
<robclark>
airlied: that would probably be me.. but haven't had chance to look and see if it adds anything useful
<robclark>
mort_: fwiw kmemleak isn't seeing anything on sc7180 with prod kernel (5.15 with stuff backported).. so either it is a more recent regression or hw dependent
<mort_>
robclark: sc7180 is msm, right? weird. I'm on Linux 6.1.34, so it could be a recent thing
<robclark>
yeah
Duke`` has quit []
Duke`` has joined #dri-devel
<mort_>
does the put/get traces say anything at all? I had the thought that in principle, each get should have a corresponding put, so if I could pair them up, I could find the get without an associated put
<mort_>
but I found it very hard without a deeper understanding of exactly how the crtc old and new state stuff works
sima has quit [Ping timeout: 480 seconds]
vliaskov_ has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<robclark>
mort_: oh, hmm mdp5 (apq8016) vs dpu (sc7180).. that could be a difference.. but the driver doesn't really deal with the drm_crtc_commit directly, it just send the event after pageflip irq
<robclark>
fwiw, not seeing a leak on v6.4.0 with sc7180
<robclark>
and you are seeing drm_crtc_send_vblank_event() in that paste
<mort_>
robclark: do you have the ability to patch your kernel to add `pr_warn("commit_get(%p): -> %d\n", commit, commit->ref.refcount.refs.counter); dump_stack();` to the bottom of drm_crtc_commit_get and a corresponding message to the bottom of drm_crtc_commit_put?
<mort_>
that way I could get some dmesg output and compare with mine, see what put is missing or what get is superfluous
<mort_>
there's a drm_crtc_send_vblank_event in one of the traces yeah
<robclark>
doing that would absolutely flood dmesg
<mort_>
yeah :)
<robclark>
if you can, try a newer kernel? I don't really think this could be anything but a core atomic helper issue
<mort_>
I can give it a shot, but it might have to be tomorrow, it's 23:52
<mort_>
I also kinda concluded that it's hard to view this as anything other than a drm bug... I expected to find a driver which does a bunch of weird hardware specific stuff but then I found that it's 1) using the msm driver, not some Adreno 306 specific driver, and 2) the msm driver punts all the relevant stuff to drm's helpers
<robclark>
we do have db410c's in mesa and drm/igt CI.. so it should be pretty much working with upstream release kernels for a while, so narrowing down bad/good kernel versions shouldn't be too hard
<mort_>
oh, there is one thing
<mort_>
the exact manner in which I draw to the screen seems to be kinda relevant... I think there's an opportunistic optimization involved here
<mort_>
this sd410 has a 1080p screen attached to it, and is running X; in most configurations, it doesn't hit 60 FPS, even a basic glClear() + glfwSwapBuffers() loop will hit 40-50, and the slab allocator reports no leaks
<mort_>
but when I make the window dimensions exactly 1920x1080, and enable both vsync and double buffering, I hit 60 FPS, and I leak 256 bytes per frame
<mort_>
that's something I should check tomorrow, how exactly the traces from the unoptimized situation compares against the traces from the optimized situation
<robclark>
so that isn't too surprising, X (without a compositing window mgr) will be doing blits to front buffer for windowed
<robclark>
so probably just aren't getting any kms ioctl
<robclark>
but vsync'd fullscreen woudl be pageflip ioctls every frame
<mort_>
eh we'll see, only two relatively non-essential patches failed to apply, I was fearing every patch would fail to apply and the resulting kernel wouldn't even have a working display
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
RSpliet has quit [Read error: Connection reset by peer]
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
<mareko>
zmike: we should have a test for it if we don't; if we do, then it works for me
<zmike>
mareko: can you clarify what "it" is in this context?